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

[zan at falconsigh.net]

On Wed, Dec 9, 2015, at 05:37 PM, 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.
> 
> > > 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.
> 

Well, to paraphrase further, ideally we only need a shovel, but
apparently
its blade would bend half of the time we'd use it. Let's not paraphrase
further :>

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

Yeah, I agree with that. Martin volunteered to push the current nested
compositor work into trunk.

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

As it was mentioned, GtkOverlay widget is one case where additional
operations would be required by the toolkit to provide correct output.

> -- 
> Emanuele Aina
> www.collabora.com
> 
> 
> 
> _______________________________________________
> webkit-gtk mailing list
> webkit-gtk at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-gtk