Hi; On 12 January 2017 at 19:13, Bill Kelly <billk@xxxxxxx> wrote: > Howdy, > > Emmanuele Bassi wrote: >> >> If you're using macOS: there's no GL integration for this platform. > > Was there a fundamental technical limitation, or more a matter of > nobody available to make the changes for that platform? It's more of an issue of missing stable contributors and testers for the macOS backend, coupled with various issues with the Cairo port on macOS itself. There shouldn't be any technical limitation as to how GTK+ integrates OpenGL inside its rendering cycle; all we need is a GL context, and the ability to take a render buffer (either a literal render buffer, or a texture target) and put it inside a native window rendering surface. This is definitely more critical for GTK+ 4.x, since we are switching to OpenGL (and Vulkan) as *the* rendering API for GTK+. > I'm asking, because we're integrating GTK into a legacy Windows and > OSX application, and to support this, we recently added Foreign > Window support to GDK on OSX. > Our primary goal was to embed GTK widgets into Native views, > and we now have that working, via: > > GtkWin32EmbedWidget // This already existed, but wasn't publicly exposed > GtkQuartzEmbedWidget // New, using our GDK Foreign Window additions for OSX > > So far, so good. Not really, because GTK+ does not really like rendering outside of its rendering pipeline. I expect, for instance, that you had to disable double buffering, which is a deprecated operation because a) it's not portable b) it's a workaround to using native surfaces with out-of-frame rendering cycles. Additionally, you'll notice that you won't be able to handle things like overlaid popovers, or semi-transparent windows on top of the native window. The whole "let's embed an external windowing surface into GTK+ and expect it to render at the same time as the rest of the application" use case is untenable in modern graphics stack, and it's something we're (as a toolkit) dropping from the next major API version. It's basically impossible for the toolkit to optimise, it's also a typical scenario where there cannot be any expectation of portability. Either GTK+ is in control of what it should render, or it's not — in which case you get rendering artefacts, tearing, or obscene performance. The GL support inside GTK+ hinges on the ability of GTK+ to control when the contents of the GL target rendering buffer are going to be pushed to the windowing system, as well as the ability of the rest of the widget tree to render itself alongside the GL target: blending widgets and shadows, dealing with transparency of both the GL rendering and what is stacked underneath and on top of it. > But, our secondary goal was to get gtk-clutter-embed working similarly. > This is already functioning on Windows, but not yet on OSX. > > I had been excited to see the new GtkGLArea, thinking it would help > get Clutter using the GDK backend on OSX, and facilitate getting > gtk-clutter-embed working on that platform. That should not be a goal for anybody, really. The only way to make Clutter render appropriately using the GDK backend with GTK+ 3.x is to literally make a GDK backend for Cogl that reuses the GdkGLContext API instead of creating its own GL context, and then uses the GL context to render on an FBO, and calls gdk_cairo_draw_from_gl() with it. Anything else exposes the same issue I referred to above, which means that GtkClutterEmbed is exploiting undefined behaviour that we're currently keeping on life support until we can switch GNOME away from Clutter altogether — partially with GStreamer integration with GTK+, and partially with GTK+ 4.0 and the GSK API. > However, it sounds like we'll want to take on implementing GtkGLArea on > OSX ourselves, assuming there was no technical limitation for the lack > of GL integration you mention on this platform? As I said, there shouldn't be any technical limitation — and I'd strongly urge people to concentrate on getting GL support inside GDK and GTK+ for their platform, instead of using Clutter-GTK. > N.B. Our hope at some point is to successfully submit these changes as > a "pull request". But the changes to the Quartz backend have been fairly > substantial. Having a stable contributor to the macOS backend (I wouldn't even call it "Quartz" any more) would be very much welcome. As long as this work does not introduce any public API change, I see no problem with integrating it — considering that, currently, the macOS backend is barely tested altogether. Ciao, Emmanuele. -- https://www.bassi.io [@] ebassi [@gmail.com] _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
