Bug 99109 – webview not redrawn as needed when accelerated compositing is enabled.

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[arno.]

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.

[arno.]

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).

[arno.]

Created attachment 168303 [details]
testcase (hopefully correct this time)

[arno.]

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.

[arno.]

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.

[arno.]

Created attachment 170949 [details]
Patch

patch proposal: use gdk default display for GL shared display

[Martin Robinson]

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?

[arno.]

(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.

[Martin Robinson]

Can you fix the problem by simply using the default GDK display everywhere in RedirectedXCompositeWindow?

[arno.]

(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 ?

[Martin Robinson]

(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.

[arno.]

Created attachment 171265 [details]
Patch

updated patch: use default gdk display everywhere in RedirectedXCompositeWindow

[WebKit Review Bot]

Comment on attachment 171265 [details]
Patch

Clearing flags on attachment: 171265

Committed r132823: <http://trac.webkit.org/changeset/132823>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.