Bug 99109 - webview not redrawn as needed when accelerated compositing is enabled.
Summary: webview not redrawn as needed when accelerated compositing is enabled.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: arno.
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-11 16:01 PDT by arno.
Modified: 2012-10-29 11:01 PDT (History)
3 users (show)

See Also:


Attachments
testcase (42 bytes, text/plain)
2012-10-11 16:06 PDT, arno.
no flags Details
testcase (hopefully correct this time) (656 bytes, text/html)
2012-10-11 16:07 PDT, arno.
no flags Details
Patch (2.20 KB, patch)
2012-10-26 09:58 PDT, arno.
no flags Details | Formatted Diff | Diff
Patch (2.68 KB, patch)
2012-10-29 09:43 PDT, arno.
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description arno. 2012-10-11 16:01:59 PDT
Hi,
when accelerated compositing is enabled, the web view is sometimes not correctly updated.
This may happen when the content of a page changes, or when I reload a page.
The view is redrawn either when draw method is called directly by gtk (for example due to a Expose event), or when gtk_widget_queue_draw is called in AcceleratedCompositingContext::flushAndRenderLayers. But it is only called if 
(m_redrawPendingTime && currentTime() - m_redrawPendingTime > gScheduleDelay)
 is true, which depends mostly on luck.

It's my understanding that webview should also be redrawn on XDamageNotify event, but this event is never sent. I tried switch from catalyst to mesa drivers. I  tried to switch from a non composited window manager to a composited one. I also tried to revert bug #97472, but none of this worked: XDamageNotify never occurs.

I don't known what to do to investigate more now.
Comment 1 arno. 2012-10-11 16:06:05 PDT
Created attachment 168302 [details]
testcase

testcase:
display the page, and do not do anything (like moving the mouse). After 2 seconds, the text should change from hello to goodbye.
When I display the page on GtkLauncher with accelerated compositing enabled, the text is not updated until I click inside the page (or switch to it with the keyboard).
Comment 2 arno. 2012-10-11 16:07:03 PDT
Created attachment 168303 [details]
testcase (hopefully correct this time)
Comment 3 arno. 2012-10-11 16:12:03 PDT
For some reason, when runned from webkit.org, the testcase works correctly. But if I reload, it fails.
Anyway, I can see by putting printf in filterXDamageEvent that XDamageNotify  even does not occur.
Comment 4 arno. 2012-10-26 09:57:01 PDT
What happens is display from GLContext::shaderX11Display has not been wrapped in a GdkDisplay, and therefore, events for that display are not captured in the gtk event handler.
Comment 5 arno. 2012-10-26 09:58:50 PDT
Created attachment 170949 [details]
Patch

patch proposal: use gdk default display for GL shared display
Comment 6 Martin Robinson 2012-10-26 10:52:33 PDT
What use of GLContext::sharedX11Display is causing the issue. The one in platform/graphics/glx/GLContextGLX.cpp or the one in platform/gtk/RedirectedXCompositeWindow.cpp?
Comment 7 arno. 2012-10-26 11:03:04 PDT
(In reply to comment #6)
> What use of GLContext::sharedX11Display is causing the issue. The one in platform/graphics/glx/GLContextGLX.cpp or the one in platform/gtk/RedirectedXCompositeWindow.cpp?

RedirectedXCompositeWindow
we call 
gdk_window_add_filter(0, reinterpret_cast<GdkFilterFunc>(filterXDamageEvent), 0);
Currently, we get some events in filterXDamageEvent but they are not related to GL shared display.
Comment 8 Martin Robinson 2012-10-26 11:12:07 PDT
Can you fix the problem by simply using the default GDK display everywhere in RedirectedXCompositeWindow?
Comment 9 arno. 2012-10-26 11:57:00 PDT
(In reply to comment #8)
> Can you fix the problem by simply using the default GDK display everywhere in RedirectedXCompositeWindow?

This works. But then, redirected window and gl context will be related to different displays. There is a comment near GLContext::sharedX11Display stating:

// We do not want to call glXMakeContextCurrent using different Display pointers,
// because it might lead to crashes in some drivers (fglrx).

Even though my testcase does not crash with fglrx, do you known if we might trigger this bug by using the default display in redirected comp window, and another one in glContext ?
Comment 10 Martin Robinson 2012-10-26 22:38:12 PDT
(In reply to comment #9)
> (In reply to comment #8)

> Even though my testcase does not crash with fglrx, do you known if we might trigger this bug by using the default display in redirected comp window, and another one in glContext ?

I believe the issue is only with calling glXMakeCurrent.
Comment 11 arno. 2012-10-29 09:43:04 PDT
Created attachment 171265 [details]
Patch

updated patch: use default gdk display everywhere in RedirectedXCompositeWindow
Comment 12 WebKit Review Bot 2012-10-29 11:01:35 PDT
Comment on attachment 171265 [details]
Patch

Clearing flags on attachment: 171265

Committed r132823: <http://trac.webkit.org/changeset/132823>
Comment 13 WebKit Review Bot 2012-10-29 11:01:40 PDT
All reviewed patches have been landed.  Closing bug.