[email protected] 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 _______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
