Re: GtkGLArea

[Emmanuele Bassi <ebassi gmail com>]

Hi;

On 12 January 2017 at 19:13, Bill Kelly <billk cts com> 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]