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

[Daniel Stone]

Hi,

On Wed, 2015-12-09 at 17:37 +0100, Emanuele Aina wrote:
> 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.

Right. wl_drm is a very specific implementation of the Wayland EGL
platform. The reason they can be addressed in the Wayland EGL platform
and not libgbm is very very simple: Wayland-EGL is a general-purpose
platform that is able to adapt to its surroundings. libgbm is not, and
very specifically pessimises for one usecase.

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

To be fair, having a nested compositor (not to be confused with the
wl_subcompositor interface to allow subsurfaces) is surprisingly little
overhead, and the complexity - we feel - is mostly necessary.

Cheers,
Daniel