Bug 73842

Summary:

Allow the ImageBuffers used by SVG filters to be accelerated

Product:

WebKit

Reporter:

Stephen White <senorblanco>

Component:

SVG

Assignee:

Stephen White <senorblanco>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

dino, fishd, jamesr, kbr, webkit.review.bot, zherczeg, zimmermann

Priority:

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

See Also:

https://bugs.webkit.org/show_bug.cgi?id=235376

Attachments:

Description	Flags
Patch	none
Patch	none

Stephen White

Reported 2011-12-05 10:32:10 PST

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

Attachments
Patch (19.47 KB, patch) 2011-12-05 10:38 PST, Stephen White	no flags	Details Formatted Diff Diff
Patch (20.23 KB, patch) 2011-12-05 11:10 PST, Stephen White	no flags	Details Formatted Diff Diff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.

Stephen White

Comment 1 2011-12-05 10:38:39 PST

Created attachment 117898 [details] Patch

WebKit Review Bot

Comment 2 2011-12-05 10:48:24 PST

Please wait for approval from fishd@chromium.org before submitting because this patch contains changes to the Chromium public API.

Darin Fisher (:fishd, Google)

Comment 3 2011-12-05 11:03:21 PST

Comment on attachment 117898 [details] Patch WebKit API changes LGTM

Stephen White

Comment 4 2011-12-05 11:10:05 PST

Created attachment 117903 [details] Patch

Zoltan Herczeg

Comment 5 2011-12-05 13:01:06 PST

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

Stephen White

Comment 6 2011-12-05 13:26:36 PST

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 7 2011-12-05 15:01:41 PST

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

Comment 8 2011-12-05 15:31:40 PST

(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 9 2011-12-05 15:34:11 PST

Comment on attachment 117903 [details] Patch OK, this seems reasonable. r=me

Dean Jackson

Comment 10 2011-12-05 17:12:10 PST

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

WebKit Review Bot

Comment 11 2011-12-05 20:16:46 PST

Comment on attachment 117903 [details] Patch Clearing flags on attachment: 117903 Committed r102088: <http://trac.webkit.org/changeset/102088>

WebKit Review Bot

Comment 12 2011-12-05 20:16:51 PST

All reviewed patches have been landed. Closing bug.

Note You need to log in before you can comment on or make changes to this bug.