<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><meta http-equiv="content-type" content="text/html; charset=utf-8" />
<title>[204961] trunk/Source/WebKit2</title>
</head>
<body>
<style type="text/css"><!--
#msg dl.meta { border: 1px #006 solid; background: #369; padding: 6px; color: #fff; }
#msg dl.meta dt { float: left; width: 6em; font-weight: bold; }
#msg dt:after { content:':';}
#msg dl, #msg dt, #msg ul, #msg li, #header, #footer, #logmsg { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt; }
#msg dl a { font-weight: bold}
#msg dl a:link { color:#fc3; }
#msg dl a:active { color:#ff0; }
#msg dl a:visited { color:#cc6; }
h3 { font-family: verdana,arial,helvetica,sans-serif; font-size: 10pt; font-weight: bold; }
#msg pre { overflow: auto; background: #ffc; border: 1px #fa0 solid; padding: 6px; }
#logmsg { background: #ffc; border: 1px #fa0 solid; padding: 1em 1em 0 1em; }
#logmsg p, #logmsg pre, #logmsg blockquote { margin: 0 0 1em 0; }
#logmsg p, #logmsg li, #logmsg dt, #logmsg dd { line-height: 14pt; }
#logmsg h1, #logmsg h2, #logmsg h3, #logmsg h4, #logmsg h5, #logmsg h6 { margin: .5em 0; }
#logmsg h1:first-child, #logmsg h2:first-child, #logmsg h3:first-child, #logmsg h4:first-child, #logmsg h5:first-child, #logmsg h6:first-child { margin-top: 0; }
#logmsg ul, #logmsg ol { padding: 0; list-style-position: inside; margin: 0 0 0 1em; }
#logmsg ul { text-indent: -1em; padding-left: 1em; }#logmsg ol { text-indent: -1.5em; padding-left: 1.5em; }
#logmsg > ul, #logmsg > ol { margin: 0 0 1em 0; }
#logmsg pre { background: #eee; padding: 1em; }
#logmsg blockquote { border: 1px solid #fa0; border-left-width: 10px; padding: 1em 1em 0 1em; background: white;}
#logmsg dl { margin: 0; }
#logmsg dt { font-weight: bold; }
#logmsg dd { margin: 0; padding: 0 0 0.5em 0; }
#logmsg dd:before { content:'\00bb';}
#logmsg table { border-spacing: 0px; border-collapse: collapse; border-top: 4px solid #fa0; border-bottom: 1px solid #fa0; background: #fff; }
#logmsg table th { text-align: left; font-weight: normal; padding: 0.2em 0.5em; border-top: 1px dotted #fa0; }
#logmsg table td { text-align: right; border-top: 1px dotted #fa0; padding: 0.2em 0.5em; }
#logmsg table thead th { text-align: center; border-bottom: 1px solid #fa0; }
#logmsg table th.Corner { text-align: left; }
#logmsg hr { border: none 0; border-top: 2px dashed #fa0; height: 1px; }
#header, #footer { color: #fff; background: #636; border: 1px #300 solid; padding: 6px; }
#patch { width: 100%; }
#patch h4 {font-family: verdana,arial,helvetica,sans-serif;font-size:10pt;padding:8px;background:#369;color:#fff;margin:0;}
#patch .propset h4, #patch .binary h4 {margin:0;}
#patch pre {padding:0;line-height:1.2em;margin:0;}
#patch .diff {width:100%;background:#eee;padding: 0 0 10px 0;overflow:auto;}
#patch .propset .diff, #patch .binary .diff {padding:10px 0;}
#patch span {display:block;padding:0 10px;}
#patch .modfile, #patch .addfile, #patch .delfile, #patch .propset, #patch .binary, #patch .copfile {border:1px solid #ccc;margin:10px 0;}
#patch ins {background:#dfd;text-decoration:none;display:block;padding:0 10px;}
#patch del {background:#fdd;text-decoration:none;display:block;padding:0 10px;}
#patch .lines, .info {color:#888;background:#fff;}
--></style>
<div id="msg">
<dl class="meta">
<dt>Revision</dt> <dd><a href="http://trac.webkit.org/projects/webkit/changeset/204961">204961</a></dd>
<dt>Author</dt> <dd>carlosgc@webkit.org</dd>
<dt>Date</dt> <dd>2016-08-25 08:39:09 -0700 (Thu, 25 Aug 2016)</dd>
</dl>
<h3>Log Message</h3>
<pre>[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.</pre>
<h3>Modified Paths</h3>
<ul>
<li><a href="#trunkSourceWebKit2ChangeLog">trunk/Source/WebKit2/ChangeLog</a></li>
<li><a href="#trunkSourceWebKit2WebProcessWebPageCoordinatedGraphicsThreadedCoordinatedLayerTreeHostcpp">trunk/Source/WebKit2/WebProcess/WebPage/CoordinatedGraphics/ThreadedCoordinatedLayerTreeHost.cpp</a></li>
</ul>
</div>
<div id="patch">
<h3>Diff</h3>
<a id="trunkSourceWebKit2ChangeLog"></a>
<div class="modfile"><h4>Modified: trunk/Source/WebKit2/ChangeLog (204960 => 204961)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/WebKit2/ChangeLog 2016-08-25 09:53:58 UTC (rev 204960)
+++ trunk/Source/WebKit2/ChangeLog 2016-08-25 15:39:09 UTC (rev 204961)
</span><span class="lines">@@ -1,3 +1,25 @@
</span><ins>+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.
+
</ins><span class="cx"> 2016-08-24 JF Bastien <jfbastien@apple.com>
</span><span class="cx">
</span><span class="cx"> cmake build broken by MessageRecorder removal
</span></span></pre></div>
<a id="trunkSourceWebKit2WebProcessWebPageCoordinatedGraphicsThreadedCoordinatedLayerTreeHostcpp"></a>
<div class="modfile"><h4>Modified: trunk/Source/WebKit2/WebProcess/WebPage/CoordinatedGraphics/ThreadedCoordinatedLayerTreeHost.cpp (204960 => 204961)</h4>
<pre class="diff"><span>
<span class="info">--- trunk/Source/WebKit2/WebProcess/WebPage/CoordinatedGraphics/ThreadedCoordinatedLayerTreeHost.cpp 2016-08-25 09:53:58 UTC (rev 204960)
+++ trunk/Source/WebKit2/WebProcess/WebPage/CoordinatedGraphics/ThreadedCoordinatedLayerTreeHost.cpp 2016-08-25 15:39:09 UTC (rev 204961)
</span><span class="lines">@@ -145,12 +145,25 @@
</span><span class="cx">
</span><span class="cx"> void ThreadedCoordinatedLayerTreeHost::setVisibleContentsRect(const FloatRect& rect, const FloatPoint& trajectoryVector, float scale)
</span><span class="cx"> {
</span><del>- CoordinatedLayerTreeHost::setVisibleContentsRect(rect, trajectoryVector);
- if (m_lastScrollPosition != roundedIntPoint(rect.location())) {
- m_lastScrollPosition = roundedIntPoint(rect.location());
</del><ins>+ FloatRect visibleRect(rect);
</ins><span class="cx">
</span><del>- if (!m_webPage.corePage()->mainFrame().view()->useFixedLayout())
- m_webPage.corePage()->mainFrame().view()->notifyScrollPositionChanged(m_lastScrollPosition);
</del><ins>+ // 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);
</ins><span class="cx"> }
</span><span class="cx">
</span><span class="cx"> if (m_lastScaleFactor != scale) {
</span></span></pre>
</div>
</div>
</body>
</html>