Bug 219423 – [GPU Process] Allow CSSFilters and SVGFilters to use RemoteImageBuffers if GPU DOM rendering is enabled

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Layout and Rendering

[Said Abou-Hallawa]

The filters are drawing commands and filter effects commands. The first step is to move the drawing commands to the GPU Process.

[Said Abou-Hallawa]

Created attachment 415198 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 415198 [details]
Patch

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

> Source/WebCore/platform/graphics/filters/Filter.h:37
> -    Filter(const AffineTransform& absoluteTransform, float filterScale = 1)
> +    Filter(const AffineTransform& absoluteTransform, float filterScale = 1, HostWindow* hostWindow = nullptr)
>          : m_absoluteTransform(absoluteTransform)

I don't think this is the right approach. Filter is much too low-level a class to deal with HostWindow.

[Said Abou-Hallawa]

Comment on attachment 415198 [details]
Patch

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

>> Source/WebCore/platform/graphics/filters/Filter.h:37
>>          : m_absoluteTransform(absoluteTransform)
> 
> I don't think this is the right approach. Filter is much too low-level a class to deal with HostWindow.

ImageBuffer deals with HostWindow and ImageBuffer is even in a lower level than Filter because Filter owns and creates the ImageBuffer. So why is it okay to make imageBuffer deal with HostWindow but not for the Filter?

[Simon Fraser (smfr)]

(In reply to Said Abou-Hallawa from comment #3)
> Comment on attachment 415198 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=415198&action=review
> 
> >> Source/WebCore/platform/graphics/filters/Filter.h:37
> >>          : m_absoluteTransform(absoluteTransform)
> > 
> > I don't think this is the right approach. Filter is much too low-level a class to deal with HostWindow.
> 
> ImageBuffer deals with HostWindow and ImageBuffer is even in a lower level
> than Filter because Filter owns and creates the ImageBuffer. So why is it
> okay to make imageBuffer deal with HostWindow but not for the Filter?

Filter is a lightweight mostly-data class which is context-free (which is a good thing). If it has a HostWindow then it's encumbered with more state.

If we need a usage of HostWindow, it should be passed in as an argument to functions where Filters create ImageBuffers, but not stored as a member variable.

And this would look much nicer if what was passed in was an ImageBufferFactory, not a HostWindow.

[Said Abou-Hallawa]

Created attachment 415286 [details]
Patch

[Simon Fraser (smfr)]

Comment on attachment 415286 [details]
Patch

Let's make adding ImageBufferFactory its own patch.

[Said Abou-Hallawa]

Created attachment 415327 [details]
Patch

[Radar WebKit Bug Importer]

<rdar://problem/72128302>

[Said Abou-Hallawa]

The approach of this patch was incorrect. This correct approach was taken by bug 231253.

*** This bug has been marked as a duplicate of bug 231253 ***