RESOLVED FIXED 105652
RenderLayerCompositor should let ScrollingCoordinator update main thread scrolling reasons after change of layers
https://bugs.webkit.org/show_bug.cgi?id=105652
Summary RenderLayerCompositor should let ScrollingCoordinator update main thread scro...
Xianzhu Wang
Reported 2012-12-21 12:41:17 PST
On Chromium ScrollingCoordinator will force main thread scrolling if there are any viewport-constrained objects not composited. However, sometimes (e.g. when the page is loading) the main thread scrolling reasons are not updated immediately after RLC promotes some fixed position elements to composited layers. This causes slow scrolling before the main thread scrolling reasons are correctly updated. crbug.com/167312 describes the slow scrolling case.
Attachments
Patch (12.36 KB, patch)
2012-12-21 17:32 PST, Xianzhu Wang
no flags
Patch (26.60 KB, patch)
2013-01-08 14:35 PST, Xianzhu Wang
no flags
Fix mac break (27.84 KB, patch)
2013-01-08 15:37 PST, Xianzhu Wang
no flags
for landing (27.88 KB, patch)
2013-01-11 10:35 PST, Xianzhu Wang
no flags
Xianzhu Wang
Comment 1 2012-12-21 17:32:20 PST
Simon Fraser (smfr)
Comment 2 2013-01-02 21:37:39 PST
Comment on attachment 180578 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=180578&action=review > Source/WebCore/rendering/RenderLayerCompositor.cpp:473 > + if (scrollingCoordinator && m_fixedPositionLayerNotCompositedReasonMap != originalFixedPositionLayerNotCompositedReasonMap) I don't really like m_fixedPositionLayerNotCompositedReasonMap, and the fact that you're comparing two HashMaps here.
Xianzhu Wang
Comment 3 2013-01-07 15:23:24 PST
(In reply to comment #2) > (From update of attachment 180578 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=180578&action=review > > > Source/WebCore/rendering/RenderLayerCompositor.cpp:473 > > + if (scrollingCoordinator && m_fixedPositionLayerNotCompositedReasonMap != originalFixedPositionLayerNotCompositedReasonMap) > > I don't really like m_fixedPositionLayerNotCompositedReasonMap, and the fact that you're comparing two HashMaps here. (I thought I posted the following on last Friday, but just found I made it lost somehow) How about moving the reason information map into individual RenderLayers or RenderLayerModelObjects as a new field?
Xianzhu Wang
Comment 4 2013-01-08 14:35:46 PST
Build Bot
Comment 5 2013-01-08 15:17:26 PST
Xianzhu Wang
Comment 6 2013-01-08 15:37:37 PST
Created attachment 181789 [details] Fix mac break
Xianzhu Wang
Comment 7 2013-01-10 09:32:05 PST
Simon, do you like the latest patch?
Xianzhu Wang
Comment 8 2013-01-11 09:55:16 PST
Kindly ping reviewers...
Simon Fraser (smfr)
Comment 9 2013-01-11 10:18:56 PST
Comment on attachment 181789 [details] Fix mac break View in context: https://bugs.webkit.org/attachment.cgi?id=181789&action=review Nice cleanup, thanks! > Source/WebCore/rendering/RenderLayerCompositor.cpp:636 > + if (layerChanged) > + if (ScrollingCoordinator* scrollingCoordinator = this->scrollingCoordinator()) > + scrollingCoordinator->frameViewFixedObjectsDidChange(m_renderView->frameView()); We put {} around multi-line conditional blocks like this.
Xianzhu Wang
Comment 10 2013-01-11 10:35:54 PST
Created attachment 182365 [details] for landing
Xianzhu Wang
Comment 11 2013-01-11 10:36:34 PST
Comment on attachment 181789 [details] Fix mac break View in context: https://bugs.webkit.org/attachment.cgi?id=181789&action=review >> Source/WebCore/rendering/RenderLayerCompositor.cpp:636 >> + scrollingCoordinator->frameViewFixedObjectsDidChange(m_renderView->frameView()); > > We put {} around multi-line conditional blocks like this. Done.
WebKit Review Bot
Comment 12 2013-01-11 10:59:06 PST
Comment on attachment 182365 [details] for landing Clearing flags on attachment: 182365 Committed r139461: <http://trac.webkit.org/changeset/139461>
WebKit Review Bot
Comment 13 2013-01-11 10:59:11 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.