Bug 73842 - Allow the ImageBuffers used by SVG filters to be accelerated
Summary: Allow the ImageBuffers used by SVG filters to be accelerated
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: SVG (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Stephen White
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-05 10:32 PST by Stephen White
Modified: 2011-12-05 20:16 PST (History)
7 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Stephen White 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.
Comment 1 Stephen White 2011-12-05 10:38:39 PST
Created attachment 117898 [details]
Patch
Comment 2 WebKit Review Bot 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.
Comment 3 Darin Fisher (:fishd, Google) 2011-12-05 11:03:21 PST
Comment on attachment 117898 [details]
Patch

WebKit API changes LGTM
Comment 4 Stephen White 2011-12-05 11:10:05 PST
Created attachment 117903 [details]
Patch
Comment 5 Zoltan Herczeg 2011-12-05 13:01:06 PST
What does this change exactly accelerate? It just sets a bool value...
Comment 6 Stephen White 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.
Comment 7 Kenneth Russell 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?
Comment 8 Stephen White 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.
Comment 9 Kenneth Russell 2011-12-05 15:34:11 PST
Comment on attachment 117903 [details]
Patch

OK, this seems reasonable. r=me
Comment 10 Dean Jackson 2011-12-05 17:12:10 PST
We'll (Apple'll) need to expose this via WebPreferences.
Comment 11 WebKit Review Bot 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>
Comment 12 WebKit Review Bot 2011-12-05 20:16:51 PST
All reviewed patches have been landed.  Closing bug.