<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] Graphics corruption when entering/leaving AC mode quickly"
href="https://bugs.webkit.org/show_bug.cgi?id=150323">150323</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>[GTK] Graphics corruption when entering/leaving AC mode quickly
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>Product</th>
<td>WebKit
</td>
</tr>
<tr>
<th>Version</th>
<td>WebKit Nightly Build
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Unspecified
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Keywords</th>
<td>Gtk
</td>
</tr>
<tr>
<th>Severity</th>
<td>Normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P2
</td>
</tr>
<tr>
<th>Component</th>
<td>WebKit Gtk
</td>
</tr>
<tr>
<th>Assignee</th>
<td>webkit-unassigned@lists.webkit.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>mario@webkit.org
</td>
</tr>
<tr>
<th>CC</th>
<td>bugs-noreply@webkitgtk.org, cgarcia@igalia.com, mrobinson@webkit.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=263467" name="attach_263467" title="Reduced test case">attachment 263467</a> <a href="attachment.cgi?id=263467&action=edit" title="Reduced test case">[details]</a></span>
Reduced test case
DESCRIPTION
Starting with WebKit2GTK+ 2.8, there seems to be an issue that happens sometimes when Accelerated Compositing mode is exited and then re-activated again very quickly, which sometimes can lead to some weird "flickering effects", where the webview would show wrong contents for a split second.
More specifically, in my case I could see at least 3 manifestations of this issue, which I think it could be a sign of a memory corruption issue in the backing store:
A. The webview displays a previous rendering state for a split second, then quickly switches to its current state again
B. The webview refuses to load the contents of an image, which could be never shown in the end if belonging to an animation (where the image would be shown only for a moment)
C. The webview shows some corrupted pixels at the top for a moment
I've debugged this issue for a while already and found that in WebKit2GTK+ 2.6 and previous versions the PageClientImpl::enterAcceleratedCompositingMode() and PageClientImpl::exitAcceleratedCompositingMode() where not implemented, while now they are implemented to cause a resize of both the XRedirectedCompositeWindow used for AC, and the drawing area (only on entering AC), so I believe that's the crucial difference that exposed the problem now, and why I could not see it in 2.6 at all.
Now, trying to come up with a reliable test case to prove this issue I wrote a simple test HTML which I can use to reproduce at least (B) and (C) in my laptop, using WebKit upstream (r191124) and MiniBrowser, which I'm attaching right now. (A) is harder to reproduce as a simplified test case, so forgive me for not providing a reliable test for it, but the other two problems I can reproduce them with this test case relatively easy (as in 3/10) in my laptop.
STEPS TO REPRODUCE
1. Uncompress the contents of the attached file and load index.html in MiniBrowser
2. You should see some small text together with a black box underneath for a split second, then just some text without any black box around
3. Press Ctrl+R to refresh and repeat step 2
4. Repeat steps 2-3 a bunch of times (e.g. 20 times or so)
EXPECTED OUTCOME:
Whenever you refresh, you should ALWAYS see a black box underneath the text that shows up briefly text, and then no black box at all when the second text is shown
ACTUAL OUTCOME:
Sometimes the black box is not shown together with the initial text when refreshing, sometimes some corrupted graphics are rendered at the top of the web view. Sometimes it works ok, too!
OTHER COMMENTS:
Notice that the problems mentioned above do NOT HAPPEN AT ALL if Accelerated Compositing mode stayed ON ALL THE TIME while the test is run (instead of exitting/re-entering quickly, which is what that test forces).
In order to try this out yourself, simply uncomment lines 22-24 in the attached test case and repear the STEPS above. In this case, you should never see the problems and the EXPECTED OUTCOME should be the actual time, everytime you refresh.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>