hiro gtk3: Support native Wayland display

[Screwtapello]

Currently, when you build bsnes with hiro=gtk3, it works well enough under X11, but it crashes when run under Wayland. That's because hiro does a lot of things directly via Xlib since GTK2 didn't provide an API for them. Often GTK3 does provide an API for them, but to keep GTK2 and GTK3 supported side-by-side, hiro uses the same Xlib code for both.

You can run bsnes with GTK3 under Wayland if you set GDK_BACKEND=x11 in the environment before running it, and assuming your Wayland compositor has XWayland support enabled (which they probably all do).

[Screwtapello]

This will probably be made more complex by ruby - I think it use Xlib to create a custom window for each video backend and reparents it into whatever window the application is using. That won't work for Wayland, since reparenting isn't a thing there. On the other hand, GTK+3 provides a native OpenGL widget.

Currently hiro/ruby assume that non-Windows and non-macOS is POSIX and X11, but maybe we need another POSIX non-X11 platform for Wayland.

[Alcaro]

We already have parent window ID in Ruby, no need for reparenting. Though I've never used Wayland, perhaps normal child windows are already a showstopper.

GtkGLArea is quite different from the existing GL and not-GL backends (GTK widgets don't have window IDs; needs gtk_gl_area_attach_buffers() rather than glBindFramebuffer(0) for the actual output, which likely requires an extra copy or some annoying refactoring; the equivalent of glXSwapBuffers seems to be returning from the render signal, which may also require some refactorings).

I recommend using EGL if possible. If not possible, and if GtkGLArea would require too ugly refactorings, a third option would be using the GDK/GL API directly (here's an example on how to use it, though it still seems to have some of GtkGLArea's quirks).

[rtretiakov]

It is my understanding that the correct way to do this in Wayland is with subsurfaces:
https://wayland-book.com/surfaces-in-depth/subsurfaces.html

Since on Linux there are only OpenGL 3.2/2.0 drivers outside of X-specific stuff, the GL widget is probably the best choice as it hides these details from you. I have not looked at ruby to determine what's going on there yet.

I believe the GTK3 GL widget only supports core profile, so that would mean deprecating OpenGL 2.0 support for use under Wayland. Correct me if I'm wrong here.

[plaes]

It is my understanding that the correct way to do this in Wayland is with subsurfaces:
https://wayland-book.com/surfaces-in-depth/subsurfaces.html

Since on Linux there are only OpenGL 3.2/2.0 drivers outside of X-specific stuff, the GL widget is probably the best choice as it hides these details from you. I have not looked at ruby to determine what's going on there yet.

I believe the GTK3 GL widget only supports core profile, so that would mean deprecating OpenGL 2.0 support for use under Wayland. Correct me if I'm wrong here.

Upstream issue: https://gitlab.gnome.org/GNOME/gtk/-/issues/2619

[sonic2kk]

Hopefully this gets resolved soon (including upstream), as this partially impacts HiDPI support on Plasma Wayland - Xwayland applications appear blurry when on scaled displays.