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

[zan at falconsigh.net]

On Wed, Dec 9, 2015, at 06:04 PM, Emanuele Aina wrote:
> 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™.
> 

Hm, I see. I guess I wasn't paying enough attention in the breakout
sessions.

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