Bug 73842 – Allow the ImageBuffers used by SVG filters to be accelerated

• Status: RESOLVED
• Resolution: FIXED
• Component: SVG

[Stephen White]

There should be a Setting to enable the ImageBuffers created for SVG filters to be created in Accelerated mode.

[Stephen White]

Created attachment 117898 [details]
Patch

[WebKit Review Bot]

Please wait for approval from [e-mail] before submitting because this patch contains changes to the Chromium public API.

[Darin Fisher (:fishd, Google)]

Comment on attachment 117898 [details]
Patch

WebKit API changes LGTM

[Stephen White]

Created attachment 117903 [details]
Patch

[Zoltan Herczeg]

What does this change exactly accelerate? It just sets a bool value...

[Stephen White]

reply to comment #5)
> What does this change exactly accelerate? It just sets a bool value...

That bool value is used inside ImageBuffer in order to create GPU-based backing stores, and to do all draw operations using the GPU (on some ports).  This means the drawing of the initial SVG primitive is accelerated, as well as a number of FilterEffect nodes which use only GraphicsContext calls for drawing.

It also puts the infrastructure in place for acceleration of subsequent FE nodes, through additions to the GraphicsContext API.

[Kenneth Russell]

Comment on attachment 117903 [details]
Patch

This looks fine to me. One question: since the flag is exposed on a per-page basis, is there any issue with wanting finer grained control of acceleration? For example, GPU accelerating some filters but not others?

[Stephen White]

(In reply to comment #7)
> (From update of attachment 117903 [details])
> This looks fine to me. One question: since the flag is exposed on a per-page basis, is there any issue with wanting finer grained control of acceleration? For example, GPU accelerating some filters but not others?

Right now, the accelerated filters "play well" with the unaccelerated ones, in that a readback or upload is triggered as necessary, while consecutive accelerated filters will all stay on the GPU.  That said, as we accelerate more filters, we eliminate those readbacks, so I don't really see much benefit in allowing a port to re-introduce them selectively.

[Kenneth Russell]

Comment on attachment 117903 [details]
Patch

OK, this seems reasonable. r=me

[Dean Jackson]

We'll (Apple'll) need to expose this via WebPreferences.

[WebKit Review Bot]

Comment on attachment 117903 [details]
Patch

Clearing flags on attachment: 117903

Committed r102088: <http://trac.webkit.org/changeset/102088>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.