[Webkit-unassigned] [Bug 150323] New: [GTK] Graphics corruption when entering/leaving AC mode quickly

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Oct 19 03:52:59 PDT 2015


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

            Bug ID: 150323
           Summary: [GTK] Graphics corruption when entering/leaving AC
                    mode quickly
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Linux
            Status: NEW
          Keywords: Gtk
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: mario at webkit.org
                CC: bugs-noreply at webkitgtk.org, cgarcia at igalia.com,
                    mrobinson at webkit.org

Created attachment 263467
  --> https://bugs.webkit.org/attachment.cgi?id=263467&action=review
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.

-- 
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/20151019/d73bd69b/attachment-0001.html>


More information about the webkit-unassigned mailing list