[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)
commitf66a627b78ce54e71ff0a72e905c71d5dc0efd6a
treed661e309f6116a3c2dd1f9c7e7669e5bb19d0242
parent59d9c8f109ec1a2c05369fe471d7c52d5caeed1f
[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.

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