The current Accelerated Compositing infrastructure in WebKit2GTK+ relies on the WebProcess painting directly to a X Window owned by the UIProcess, which is suboptimal due to the lack of integration with the UIProcess paint loop (no synchronization between the WebView contents and other widgets and no ability to stack other widgets on top of the WebView). Ideally we should do what the Mac port does and export each layer from the WebProcess(es) and let the UIProcess composite them in its paint loop. GdkGLContext is explicitly meant to solve both the synchronization and stacking issues.
To do that, my current understanding is that the most sensible way forward would be to rely on GdkGLContext. in the UIProcess to efficiently compose the layers, and make the UIProcess a Wayland (sub)compositor to be able to use the Wayland EGL integration (even under X, just like Weston). Differently from Žan's WebkitForWayland approach where he just need to export the handle for the final surface buffer to the WebProcess which would then use it as a GL render target, we need to be able to use the layer buffers as GL render targets in the WebProcess and as textures in the UIProcess. Exporting textures from the UIProcess as dmabufs and use them as render targets in the WebProcess is not guaranteed to work in a efficient manner, as the GL implementation may want to reallocate the storage when it wants to, e.g. to win parallelism, but export would prevent that. Also using dmabufs directly means that we should have really low-level per-platform knowledge as they are created with driver-specific ioclts. The general advice from I got is to try to look at higher layer approaches, and the most widespread abstraction over the mechanisms we need is the EGL_WL_bind_wayland_display extension [3], thus the need to be a Wayland (sub)compositor. This does not mean we should implement every Wayland feature, we only need to use the protocol to pass buffers around leaving input management to the WebKit2 infrastructure. The output-only demo nested compositor[1] in the Weston sources is around ~1k lines, whitespaces included. We could use a reduced, output-only version of the wakefield compositor experiment[2] from Alex Larsson and Jasper St. Pierre for this purpose. The sequence is more or less this: * UIProcess: calls eglGetDisplay() on the native display (Wayland or X11) * UIProcess: calls eglBindWaylandDisplayWL() to initialize EGL Wayland client support in the Wayland (sub)compositor * WebProcess: calls wl_display_connect() → wl_registry_bind() * WebProcess: calls wl_compositor_create_surface() → wl_egl_window_create() → eglCreateWindowSurface() → cairo_gl_surface_create_for_egl() to create surfaces for each layer (or just use GL on the EGLSurface) * WebProcess: uses a custom Wayland extension to synchronize the Wayland vs. custom event streams when sending the CoordinatedGraphicsState to the UIProcess * UIProcess: calls eglCreateImageKHR() on the wl_buffers received from the WebProcess * UIProcess: uses the received CoordinatedGraphicsState to composite the EGLImages using GL or even passing them with no copies to the upstream compositor with eglCreateWaylandBufferFromImageWL() [4], but this would probably require the GTK+ scene graph work to land to properly detect if other widgets overlap the WebView If GL is not available, I guess everything can be done by keeping the layers in SHM buffers, and the final compositing happens in the UIProcess using plain Cairo. Similar to the eglCreateWaylandBufferFromImageWL() case, wl_shm (as a replacement for XShm) could be used to upload some layers (eg. video frames) and avoid one copy. The same cannot be done under X since Wayland uses POSIX shared memory and X11 uses SysV shared memory. Žan, Yoon, you're the one who probably have more experience on this, would that make sense for you? Do you see any issue with the described scenario or do you believe there are more simple way to accomplish this? [1] A stand-alone, output-only reference nested compositor: http://cgit.freedesktop.org/wayland/weston/tree/clients/nested.c [2] A proof of concept of a GTK+ Wayland compositor for various situations: https://github.com/alexlarsson/wakefield [3] http://cgit.freedesktop.org/mesa/mesa/tree/docs/specs/WL_bind_wayland_display.spec [4] http://cgit.freedesktop.org/mesa/mesa/tree/docs/specs/WL_create_wayland_buffer_from_image.spec -- Emanuele Aina www.collabora.com _______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
