[Webkit-unassigned] [Bug 115803] [GTK] Accelerated compositing does not work in Wayland

[bugzilla-daemon at webkit.org]

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





--- Comment #17 from Iago Toral <itoral at igalia.com>  2014-02-27 23:57:18 PST ---
Status update:

(In reply to comment #13)
(...)
> Implementation details and known issues:
(...)
> 4. If testing AC under Wayland with a build configured for both X11 and
> Wayland targets, --disable-glx must be used, otherwise there is a bug somwehere
> that makes GTK spit out-of-memory errors when trying to paint the widget with the results of the composition and nothing is painted on the WebView.

This happens no more.

> 5. After visiting a page that enables the AC path, then leaving to another page, and then going back to the first page again using the browsers's back button shows rendering artifacts (composited layers are black). This is fixed if the page is reloaded though.

This still happens. The problem is related to WebKit's page cache. Disabling the page cache fixes it. I think the problem is that when going back to the page it tries to re-use the tiles but the underlying texture objects have been destroyed. I came to this conclusion after observing that tiles were trying to use textures with a non-zero ID (m_id in BitmapTextureGL) that had been destroyed.

This needs more investigation.

> 6. This is only a prototype and it only works with one WebView widget. Multiple
> tabs or windows are not expected to work. For this to work we will need a way
> to associate a widget with the wayland surface where we are doing the composition for that widget. This is more difficult in Wayland than in X11 because in Wayland with the nested compositor the shared Wayland surface is created in the WebProcess (LayerTreeHostGtk) where we have no context of the widget (which lives in the UI Process) and the nested compositor (which lives in the UIProcess) does not know for which widget it is creating the surfaces
> requested from the WebProcess (since the wayland protocol does not include this
> info). We might need to add a new message between the two processes to fix
> this limitation or maybe there is something more creative we can do about this.
> In any case, it needs some thinking.

This has already been addressed with the multiple surfaces patch attached to this bug.

> 7. Implementation is intended to support run-time detection of the windowing
> system (wayland or x11) and select appropriate code paths depending on the case
> by checking the type of the GdkDisplay. This needs more testing, but it seemed
> to work well for me in the following scenarios at least:
>   - Build only for X11 then run under X11
>   - Build for X11 and Wayland, then run under Wayland (*)
>   - Build for X11 and Wayland, then run under X11
> 
> (*) But this was not a complete test because as per 4) it required to
> build with --disable-glx.

I think all the cases are working fine now.

> 8. All tests were done against Weston running inside an X session, so
> there is the possibility that this needs additional fixes to work in a pure
> Wayland setup where there is no X server running. I have not tested this.
> 
> 9. I only used MiniBrowser in my tests so it would be nice to see if 
> this also works with Epiphany/Web as it is or if that would need more work.

I tested with Epiphany too since I needed it for the multiple surfaces patch and it works well.

> 10. This does not address the creation of the offscreen context for WebGL
> under Wayland, Zan was working on that and I think his fix for that should
> just work fine with my patches.

Since this will add support for the sharing context in Wayland I think it might actually solve other problems too. At least I know that bug #129244 should be fixed by this too and I wonder if the page cache issue I mention above is happening because of this as well.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.