Bug 101846 – Call to enclosingFilterLayer() in RenderObject::containerForRepaint() is expensive

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

[Simon Fraser (smfr)]

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.

[Alexandru Chiculita]

(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?

[Simon Fraser (smfr)]

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.

[Max Vujovic]

Created attachment 173979 [details]
Patch

Here's a possible patch implementing Simon's idea.

[Simon Fraser (smfr)]

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.

[Max Vujovic]

(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!

[Alexandru Chiculita]

(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.

[EFL EWS Bot]

Comment on attachment 173979 [details]
Patch

Attachment 173979 [details] did not pass efl-ews (efl):
Output: http://queues.webkit.org/results/14813952

[Max Vujovic]

Created attachment 174014 [details]
Patch

Fixing efl EWS failure. I was missing an #if ENABLE(CSS_FILTERS) guard.

[WebKit Review Bot]

Comment on attachment 174014 [details]
Patch

Clearing flags on attachment: 174014

Committed r134619: <http://trac.webkit.org/changeset/134619>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.