[GTK][Threaded Compositor] Several flaky tests due to differences in scrollbars
authorcarlosgc@webkit.org <carlosgc@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 25 Aug 2016 15:39:09 +0000 (15:39 +0000)
committercarlosgc@webkit.org <carlosgc@webkit.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Thu, 25 Aug 2016 15:39:09 +0000 (15:39 +0000)
https://bugs.webkit.org/show_bug.cgi?id=160450

Reviewed by Michael Catanzaro.

The issue is that ThreadedCompositor::didChangeVisibleRect() dispatches the setVisibleContentsRect() call that
ends up in CompositingCoordinator. Since we're compositing the scrollbars as well, this visible contents rect
needs to encompass the complete width of the view, but that's not happening.
In case of non-overlay scrollbars, the scrollbars are clipped from this rect, but that doesn't prevent the
scrollbar overlay layers to be flushed and rendered. What does happen is that during tile creation in the
backing store the tiles that would normally intersect the visible rect of the view (if it were spanning over the
whole actual visible area) are sorted by distance to the visible rect.
The top of the two tiles used for the scrollbar is closer to the visible rect, so that gets created and filled
in first. The second tile is stored as pending for creation, and does get rendered at the point of the next
layer flush.

* WebProcess/WebPage/CoordinatedGraphics/ThreadedCoordinatedLayerTreeHost.cpp:
(WebKit::ThreadedCoordinatedLayerTreeHost::setVisibleContentsRect): Update the visible rect taking into account
the non-overlay scrollbars before passing it to the compositor.

git-svn-id: https://svn.webkit.org/repository/webkit/trunk@204961 268f45cc-cd09-0410-ab3c-d52691b4dbfc

Source/WebKit2/ChangeLog
Source/WebKit2/WebProcess/WebPage/CoordinatedGraphics/ThreadedCoordinatedLayerTreeHost.cpp

index 823c9cf..6f732ed 100644 (file)
@@ -1,3 +1,25 @@
+2016-08-25  Carlos Garcia Campos  <cgarcia@igalia.com>
+
+        [GTK][Threaded Compositor] Several flaky tests due to differences in scrollbars
+        https://bugs.webkit.org/show_bug.cgi?id=160450
+
+        Reviewed by Michael Catanzaro.
+
+        The issue is that ThreadedCompositor::didChangeVisibleRect() dispatches the setVisibleContentsRect() call that
+        ends up in CompositingCoordinator. Since we're compositing the scrollbars as well, this visible contents rect
+        needs to encompass the complete width of the view, but that's not happening.
+        In case of non-overlay scrollbars, the scrollbars are clipped from this rect, but that doesn't prevent the
+        scrollbar overlay layers to be flushed and rendered. What does happen is that during tile creation in the
+        backing store the tiles that would normally intersect the visible rect of the view (if it were spanning over the
+        whole actual visible area) are sorted by distance to the visible rect.
+        The top of the two tiles used for the scrollbar is closer to the visible rect, so that gets created and filled
+        in first. The second tile is stored as pending for creation, and does get rendered at the point of the next
+        layer flush.
+
+        * WebProcess/WebPage/CoordinatedGraphics/ThreadedCoordinatedLayerTreeHost.cpp:
+        (WebKit::ThreadedCoordinatedLayerTreeHost::setVisibleContentsRect): Update the visible rect taking into account
+        the non-overlay scrollbars before passing it to the compositor.
+
 2016-08-24  JF Bastien  <jfbastien@apple.com>
 
         cmake build broken by MessageRecorder removal
 2016-08-24  JF Bastien  <jfbastien@apple.com>
 
         cmake build broken by MessageRecorder removal
index dbd0280..9383d87 100644 (file)
@@ -145,12 +145,25 @@ void ThreadedCoordinatedLayerTreeHost::setNativeSurfaceHandleForCompositing(uint
 
 void ThreadedCoordinatedLayerTreeHost::setVisibleContentsRect(const FloatRect& rect, const FloatPoint& trajectoryVector, float scale)
 {
 
 void ThreadedCoordinatedLayerTreeHost::setVisibleContentsRect(const FloatRect& rect, const FloatPoint& trajectoryVector, float scale)
 {
-    CoordinatedLayerTreeHost::setVisibleContentsRect(rect, trajectoryVector);
-    if (m_lastScrollPosition != roundedIntPoint(rect.location())) {
-        m_lastScrollPosition = roundedIntPoint(rect.location());
-
-        if (!m_webPage.corePage()->mainFrame().view()->useFixedLayout())
-            m_webPage.corePage()->mainFrame().view()->notifyScrollPositionChanged(m_lastScrollPosition);
+    FloatRect visibleRect(rect);
+
+    // When using non overlay scrollbars, the contents size doesn't include the scrollbars, but we need to include them
+    // in the visible area used by the compositor to ensure that the scrollbar layers are also updated.
+    // See https://bugs.webkit.org/show_bug.cgi?id=160450.
+    FrameView* view = m_webPage.corePage()->mainFrame().view();
+    Scrollbar* scrollbar = view->verticalScrollbar();
+    if (scrollbar && !scrollbar->isOverlayScrollbar())
+        visibleRect.expand(scrollbar->width(), 0);
+    scrollbar = view->horizontalScrollbar();
+    if (scrollbar && !scrollbar->isOverlayScrollbar())
+        visibleRect.expand(0, scrollbar->height());
+
+    CoordinatedLayerTreeHost::setVisibleContentsRect(visibleRect, trajectoryVector);
+    if (m_lastScrollPosition != roundedIntPoint(visibleRect.location())) {
+        m_lastScrollPosition = roundedIntPoint(visibleRect.location());
+
+        if (!view->useFixedLayout())
+            view->notifyScrollPositionChanged(m_lastScrollPosition);
     }
 
     if (m_lastScaleFactor != scale) {
     }
 
     if (m_lastScaleFactor != scale) {