Bug 225584 - Use PixelBuffer rather than ImageData in platform/ code to fix layering violation
Summary: Use PixelBuffer rather than ImageData in platform/ code to fix layering viola...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Sam Weinig
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-05-09 18:43 PDT by Sam Weinig
Modified: 2021-05-10 18:35 PDT (History)
16 users (show)

See Also:


Attachments
Patch (220.73 KB, patch)
2021-05-09 19:17 PDT, Sam Weinig
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (221.06 KB, patch)
2021-05-09 20:10 PDT, Sam Weinig
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (221.07 KB, patch)
2021-05-09 20:15 PDT, Sam Weinig
no flags Details | Formatted Diff | Diff
Patch (221.08 KB, patch)
2021-05-10 08:44 PDT, Sam Weinig
no flags Details | Formatted Diff | Diff
Patch (223.27 KB, patch)
2021-05-10 10:17 PDT, Sam Weinig
ews-feeder: commit-queue-
Details | Formatted Diff | Diff
Patch (224.95 KB, patch)
2021-05-10 14:27 PDT, Sam Weinig
no flags Details | Formatted Diff | Diff
Patch (225.01 KB, patch)
2021-05-10 16:58 PDT, Sam Weinig
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Sam Weinig 2021-05-09 18:43:38 PDT
Use PixelBuffer rather than ImageData in platform/ code to fix layering violation
Comment 1 Sam Weinig 2021-05-09 19:17:06 PDT Comment hidden (obsolete)
Comment 2 Sam Weinig 2021-05-09 20:10:50 PDT Comment hidden (obsolete)
Comment 3 Sam Weinig 2021-05-09 20:15:01 PDT Comment hidden (obsolete)
Comment 4 Sam Weinig 2021-05-10 08:44:31 PDT Comment hidden (obsolete)
Comment 5 Sam Weinig 2021-05-10 10:17:15 PDT
Created attachment 428180 [details]
Patch
Comment 6 Said Abou-Hallawa 2021-05-10 10:56:42 PDT
Can't we keep ImageData in platform code and use something like DOMImageData in the binding code? I see many idl files have names like DOM<interface>.idl: DOMWindow.idl, DOMCache.idl, DOMFileSystem.idl, etc.
Comment 7 Sam Weinig 2021-05-10 11:01:24 PDT
(In reply to Said Abou-Hallawa from comment #6)
> Can't we keep ImageData in platform code and use something like DOMImageData
> in the binding code? I see many idl files have names like
> DOM<interface>.idl: DOMWindow.idl, DOMCache.idl, DOMFileSystem.idl, etc.

We could, but what benefit would there be? There doesn't seem to be a need for RefCounted object here.
Comment 8 Said Abou-Hallawa 2021-05-10 11:06:25 PDT
The benefit is we do not have to invent a new name 'PixelBuffer'. Relating ImageData and DOMImageData is trivial and this name convention has precedent in the code.
Comment 9 Sam Weinig 2021-05-10 11:29:37 PDT
(In reply to Said Abou-Hallawa from comment #8)
> The benefit is we do not have to invent a new name 'PixelBuffer'. Relating
> ImageData and DOMImageData is trivial and this name convention has precedent
> in the code.

I think the new name is better and more descriptive. I'd rather not conflate DOM names and platform names if we can avoid it and it seems easy to do so here.
Comment 10 Sam Weinig 2021-05-10 14:27:41 PDT
Created attachment 428201 [details]
Patch
Comment 11 Sam Weinig 2021-05-10 14:29:30 PDT
(In reply to Sam Weinig from comment #9)
> (In reply to Said Abou-Hallawa from comment #8)
> > The benefit is we do not have to invent a new name 'PixelBuffer'. Relating
> > ImageData and DOMImageData is trivial and this name convention has precedent
> > in the code.
> 
> I think the new name is better and more descriptive. I'd rather not conflate
> DOM names and platform names if we can avoid it and it seems easy to do so
> here.

I'm also up for other names if you have any that you prefer, but I think tying to DOM concepts is the opposite of what we want to do in the platform layer.

Other names I considered were:

- PixelData
- ImageBufferDirect
Comment 12 Darin Adler 2021-05-10 14:49:25 PDT
Comment on attachment 428201 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=428201&action=review

> Source/WebCore/platform/graphics/PixelBuffer.cpp:39
> +    static constexpr unsigned bytesPerPixel = 4;

No need for "static" here.

> Source/WebCore/platform/graphics/filters/FilterEffect.cpp:575
> +    ASSERT(m_unmultipliedImageResult == WTF::nullopt);

I might use "!" or "!x.hasValue()" instead.

> Source/WebCore/platform/graphics/filters/FilterEffect.cpp:593
> +    ASSERT(m_premultipliedImageResult == WTF::nullopt);

Ditto.

> Source/WebCore/platform/graphics/filters/FilterEffect.h:30
> +#include "PixelBuffer.h"

Don’t need to both include and forward-declare PixelBuffer.

> Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp:587
> +    case DisplayList::ItemType::GetPixelBuffer: {
>          ASSERT_NOT_REACHED();
>          break;
>      }

No need for these braces. Also seems like we want "return WTF::nullopt" or maybe not even bother with "break".

> Source/WebKit/Shared/RemoteLayerTree/CGDisplayListImageBufferBackend.h:54
> +    void putPixelBuffer(WebCore::AlphaPremultiplication inputFormat, const WebCore::WebCore::PixelBuffer&, const WebCore::IntRect& srcRect, const WebCore::IntPoint& destPoint, WebCore::AlphaPremultiplication destFormat) override;

Does this compile? WebCore::WebCore::PixelBuffer
Comment 13 Sam Weinig 2021-05-10 16:58:10 PDT
Created attachment 428221 [details]
Patch
Comment 14 Sam Weinig 2021-05-10 17:04:33 PDT
(In reply to Darin Adler from comment #12)
> Comment on attachment 428201 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=428201&action=review
> 
> > Source/WebCore/platform/graphics/PixelBuffer.cpp:39
> > +    static constexpr unsigned bytesPerPixel = 4;
> 
> No need for "static" here.

Fixed.

> 
> > Source/WebCore/platform/graphics/filters/FilterEffect.cpp:575
> > +    ASSERT(m_unmultipliedImageResult == WTF::nullopt);
> 
> I might use "!" or "!x.hasValue()" instead.

Fixed.

> 
> > Source/WebCore/platform/graphics/filters/FilterEffect.cpp:593
> > +    ASSERT(m_premultipliedImageResult == WTF::nullopt);
> 
> Ditto.

Fixed.

> 
> > Source/WebCore/platform/graphics/filters/FilterEffect.h:30
> > +#include "PixelBuffer.h"
> 
> Don’t need to both include and forward-declare PixelBuffer.

Fixed.

> 
> > Source/WebKit/GPUProcess/graphics/RemoteRenderingBackend.cpp:587
> > +    case DisplayList::ItemType::GetPixelBuffer: {
> >          ASSERT_NOT_REACHED();
> >          break;
> >      }
> 
> No need for these braces. Also seems like we want "return WTF::nullopt" or
> maybe not even bother with "break".

Fixed.

> 
> > Source/WebKit/Shared/RemoteLayerTree/CGDisplayListImageBufferBackend.h:54
> > +    void putPixelBuffer(WebCore::AlphaPremultiplication inputFormat, const WebCore::WebCore::PixelBuffer&, const WebCore::IntRect& srcRect, const WebCore::IntPoint& destPoint, WebCore::AlphaPremultiplication destFormat) override;
> 
> Does this compile? WebCore::WebCore::PixelBuffer

It did not. Fixed.
Comment 15 EWS 2021-05-10 18:34:54 PDT
Committed r277313 (237573@main): <https://commits.webkit.org/237573@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 428221 [details].
Comment 16 Radar WebKit Bug Importer 2021-05-10 18:35:17 PDT
<rdar://problem/77799571>