On Wed, Dec 9, 2015, at 05:37 PM, Emanuele Aina wrote: > [email protected] 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 > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-gtk _______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
