Bug 145554 - Calling FrameView::viewportContentsChanged() after style recalcs is too expensive
Summary: Calling FrameView::viewportContentsChanged() after style recalcs is too expen...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2015-06-02 10:58 PDT by Chris Dumez
Modified: 2015-06-02 13:21 PDT (History)
6 users (show)

See Also:


Attachments
Patch (9.09 KB, patch)
2015-06-02 11:31 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff
Patch (9.03 KB, patch)
2015-06-02 12:30 PDT, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Dumez 2015-06-02 10:58:32 PDT
Calling FrameView::viewportContentsChanged() after style recalcs is too expensive and slows down scrolling on some sites. The reason will call FrameView::viewportContentsChanged() after style recalc is to resume animations in case a composited animation brings an element inside the viewport (as these don't necessarily cause a layout). However, it is very wasteful to cause viewportContentsChanged() for every style recalc as most of them cannot cause an element to be visible without causing a layout.

We should probably rely on compositing layers being updated after the style recalc instead.

Radar: <rdar://problem/21189478>
Comment 1 Chris Dumez 2015-06-02 11:31:47 PDT
Created attachment 254075 [details]
Patch
Comment 2 Darin Adler 2015-06-02 12:06:23 PDT
Comment on attachment 254075 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=254075&action=review

> Source/WebCore/ChangeLog:22
> +        No new tests, already covered by:
> +        fast/images/animated-gif-webkit-transform.html

Unfortunate that there is no way to test the performance improvement and catch if we screw it up. We should think about a way to regression test this kind of change. I have a similar issue with my patch that cuts down on unnecessary layout when updating an image but not its dimensions.
Comment 3 Chris Dumez 2015-06-02 12:24:00 PDT
Comment on attachment 254075 [details]
Patch

Simon, can you please take a quick look as well before I land?
Comment 4 Simon Fraser (smfr) 2015-06-02 12:25:47 PDT
Comment on attachment 254075 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=254075&action=review

> Source/WebCore/rendering/RenderLayerCompositor.h:124
> +    void didRecalcStyleWithNoPendingLayout(bool& updatedCompositedLayers);

I think it would be nicer if this were just the return value, with a comment saying what the return value means.
Comment 5 Chris Dumez 2015-06-02 12:30:01 PDT
Created attachment 254080 [details]
Patch
Comment 6 Chris Dumez 2015-06-02 12:30:34 PDT
(In reply to comment #4)
> Comment on attachment 254075 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=254075&action=review
> 
> > Source/WebCore/rendering/RenderLayerCompositor.h:124
> > +    void didRecalcStyleWithNoPendingLayout(bool& updatedCompositedLayers);
> 
> I think it would be nicer if this were just the return value, with a comment
> saying what the return value means.

Ok, done.
Comment 7 WebKit Commit Bot 2015-06-02 13:21:06 PDT
Comment on attachment 254080 [details]
Patch

Clearing flags on attachment: 254080

Committed r185118: <http://trac.webkit.org/changeset/185118>
Comment 8 WebKit Commit Bot 2015-06-02 13:21:10 PDT
All reviewed patches have been landed.  Closing bug.