Changeset 156200 in webkit
- Timestamp:
- Sep 20, 2013, 2:47:38 PM (12 years ago)
- Location:
- trunk/Source/WebCore
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/Source/WebCore/ChangeLog
r156199 r156200 1 2013-09-20 Simon Fraser <simon.fraser@apple.com> 2 3 Ensure that TileController tile coverage is updated on scrolling even when we don't have scrollbars 4 https://bugs.webkit.org/show_bug.cgi?id=121700 5 <rdar://problem/15030589> 6 7 Reviewed by Dean Jackson. 8 9 r155660 introduced a bug where we wouldn't make scrollbars on long pages. However, 10 that revealed a fundamental flaw in the TiledBacking update logic; it relied on the 11 GraphicsLayer flushes triggered by scrollbars updates in order to update the main 12 TileController's tile coverage. No scrollbars meant no tile coverage updates. 13 14 Fix by explicitly triggering a flush when the FrameView is scrolled (we get 15 notified about this on the main thread after the scrolling thread has moved 16 layers around). 17 18 No test since this will only be exposed for a short time while scrollbars are 19 broken. 20 21 * rendering/RenderLayerCompositor.cpp: 22 (WebCore::RenderLayerCompositor::frameViewDidScroll): 23 1 24 2013-09-20 Zoltan Horvath <zoltan@webkit.org> 2 25 -
trunk/Source/WebCore/rendering/RenderLayerCompositor.cpp
r155892 r156200 1320 1320 // If there's a scrolling coordinator that manages scrolling for this frame view, 1321 1321 // it will also manage updating the scroll layer position. 1322 if (hasCoordinatedScrolling()) 1323 return; 1322 if (hasCoordinatedScrolling()) { 1323 // We have to schedule a flush in order for the main TiledBacking to update its tile coverage. 1324 scheduleLayerFlushNow(); 1325 return; 1326 } 1324 1327 1325 1328 FrameView& frameView = m_renderView.frameView();
Note:
See TracChangeset
for help on using the changeset viewer.