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

[Emanuele Aina]

zan at falconsigh.net wrote:

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

Ha ha ha, this perfectly describe the current situation. If only one
could rely on a good, dependable shovel! :)

To be fair to the gfx people, at least now we have the tractor, which
is definitely a huge improvement. :D

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

Ack!

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

Mh, is that the case? My understanding is that by being integrated in
the GDK paint loop, the main benefit of GdkGLContext is that *any*
widget stacking Just Works™.

-- 
Emanuele Aina
www.collabora.com