[Webkit-unassigned] [Bug 160450] [GTK][Threaded Compositor] Several flaky tests due to differences in scrollbars

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Aug 8 03:02:23 PDT 2016


https://bugs.webkit.org/show_bug.cgi?id=160450

--- Comment #8 from Zan Dobersek <zan at falconsigh.net> ---
OK, the issue is that when loading the test case in MiniBrowser, 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 mock scrollbars, the rightmost 15px 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.

None of this would be a problem if the setVisibleContentsRect() was passed a proper rect that would cover the whole view.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160808/cc4767d1/attachment.html>


More information about the webkit-unassigned mailing list