The call to enclosingFilterLayer() in RenderObject::containerForRepaint() shows up in scrolling profiles as up to 4% of the total time. It adds a second tree walk, which is terrible.
(In reply to comment #0) > The call to enclosingFilterLayer() in RenderObject::containerForRepaint() shows up in scrolling profiles as up to 4% of the total time. It adds a second tree walk, which is terrible. I can take a look at that today. Do you think that a combined tree walk will be sufficient?
Actually it's not as bad as I first thought; only 0.3% of a layout-heave trace while scrolling http://www.theverge.com/2012/10/30/3576178/apple-ipad-mini-review But it's still worth cleaning up. One thought I had was to set a bit somewhere per document (on FrameView?) that says that any filters are being used, and avoid filter-related code if not.
Created attachment 173979 [details] Patch Here's a possible patch implementing Simon's idea.
Comment on attachment 173979 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=173979&action=review I wonder if there are other bits of code we can optimize? > Source/WebCore/page/FrameView.h:374 > + bool hasSoftwareFilters() { return m_hasSoftwareFilters; } Should be const.
(In reply to comment #4) > (From update of attachment 173979 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=173979&action=review > > I wonder if there are other bits of code we can optimize? > > > Source/WebCore/page/FrameView.h:374 > > + bool hasSoftwareFilters() { return m_hasSoftwareFilters; } > > Should be const. Good catch. Thanks for the review!
(In reply to comment #4) > (From update of attachment 173979 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=173979&action=review > > I wonder if there are other bits of code we can optimize? One easy optimisation is to make RenderLayer::enclosingFilterLayer stop when it hits the first composited layer. Most probably we need to change its name too. Another optimisation is to avoid recomputing the filter result when nothing changed. We could use the invalidation process to clear the filter result. That might be useful for tile-based painting. In that case the current implementation will recompute the filter every time the paint is called. That happens even though there's no "invalidation" request between the paint calls. However, that optimisation only applies to software applied filters that require the full source image like blur, drop-shadow or custom filters. Those filters will always compute the full layer result, but will throw it away and recompute during the following paint.
Comment on attachment 173979 [details] Patch Attachment 173979 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/14813952
Created attachment 174014 [details] Patch Fixing efl EWS failure. I was missing an #if ENABLE(CSS_FILTERS) guard.
Comment on attachment 174014 [details] Patch Clearing flags on attachment: 174014 Committed r134619: <http://trac.webkit.org/changeset/134619>
All reviewed patches have been landed. Closing bug.