[webkit-gtk] WebKit2GTK+ and compositing in the UIProcess

[Emanuele Aina]

zan at falconsigh.net wrote:


> > I see. I've been told that directly using GBM buffers may still
> > face some subtle issues: for instance, since the display controller
> > is often allocating out of a fixed pool, we might end up exhausting
> > quite limited memory, and since the controller is usually more
> > restrictive in terms of the formats it can accept, compression,
> > memory location and other parameters if we reuse stuff from the GPU
> > we may end up with suboptimal configurations that cause extra
> > copies.
> 
> Are all these problems today? How are they addressed in the
> implementation of the Wayland platform in Mesa? I assume they could
> be addressed in a similar way in libgbm.

Yup, that's what I've been told. Mesa basically punts the problem down
to the wl_drm API, which is totally considered an internal
implementation detail of Mesa and not exported anywhere.

The EGL/Wayland APIs at least supposed to be portable, so they may be
even implemented by proprietary driver stacks, while wl_drm is not
meant for that.

> > Do you have a pointer to the old nested compositor implementation?
> 
> This is the meta bug:
> https://bugs.webkit.org/show_bug.cgi?id=115803

Awesome, thanks!

> > Is "just" the the introduction of another IPC mechanism?
> 
> To paraphrase, you nd up relying on the whole tractor when you just
> need the plow.

Heh, I totally agree. :/ But I'm not sure having only the plow is
actually workable in the general case for us, as it can be hard to make
it work without the tractor.

My point is that the subcompositor route is an apparently safer choice:
everybody expects it to work in every scenario: once we have in place,
nothing prevents us from looking at the lower layers and further
streamline the code if it proves workable despite the concerns raised
so far.


> > > But beyond choosing the best way to implement this, the bigger 
> > > problem is likely how to use the composition results with the 
> > > GTK+ toolkit.
> > 
> > Wouldn't using a GdkGLContext canvas provide a satisfying answer to
> > that?
> 
> It would, but we then have to jump through a bunch of hoops just to
> present the composited results correctly.

Sorry, which hoops?
Do you think that using GBM handles directly would avoid the need to
use GdkGLContext to composite the layers?

-- 
Emanuele Aina
www.collabora.com