I have been told that the X11 backend has been deprecated and is to be removed in GTK 5.
Not very long ago, applications launched with the GL rendering API by default. The default backend was then changed to Wayland, and the default rendering API to GLES.
Does the deprecation of the X11 backend mean that the enviroment variables GDK_BACKEND=x11/wayland, will no longer be available in GTK 5?
The GL rendering API has certain functionalities that are missing from the GLES rendering API, like anti-aliasing and double buffered rendering (frame-rate synchronization). In other words, when only the Wayland backend is supported, you will no longer be able to play games fluently or animate your own scenes fluently from within a GTK 5 window.
Is the Gnome development team aware of these differences between GL and GLES? Are you sure it was the right decision to deprecate the X11 backend? Playtime’s really over?
That is currently the case, yes; note that GTK5 development hasn’t started, yet, and that applications will need to be ported over once it’s released. GTK4 will also be maintained until GTK6 is released.
Wayland has been the default in GTK4 since day one. The move to GLES from GL was introduced in a development cycle in order to support more platforms. Additionally, the default rendering API is Vulkan, if available.
Exporting GDK_BACKEND=x11 will, of course, not do anything if the X11 backend does not exist any more. Whether we’ll keep the GDK_BACKEND environment variable is undecided; with the removal of the X11 backend we are back to a single backend for each platform, so backend selection is pointless.
That is not really correct. Double-buffering and frame-rate synchronisation are automatic in GTK, and anti-aliasing in GL is not something supported by every GL driver: you’re supposed to set up your own pipeline to render at a higher scale factor, and then scale down the framebuffer.
Hyperbolic statements like these never help you making your case. GTK developers are aware of the differences between GL, GLES, and Vulkan. They have nothing to do with dropping X11.
If you’re writing a game, we strongly encourage you to use Vulkan instead of GL; or, you know: use libSDL, which is meant to be used to write games.
It seems you think X11 solves your requirements, which is fair enough; but you have to realise that X11 is only ever going to be maintained as a legacy stack, and most likely running on Wayland anyway.
Sorry for the delay, I had to check some code from a while ago. It seems that the state of GL_DOUBLEBUFFER is always either GL_FALSE or irretrievable these days. That must be something new, because it did return a GL_TRUE for GDK_BACKEND=x11 and drawbuffer 0 (the default drawbuffer) not so long ago. Can’t really reproduce those results though. I can therefore neither confirm nor deny your statement on double buffered rendering being handled by GTK automatically. What was once a GL_TRUE or a GL_INVALID_ENUM, is now a GL_FALSE or a GL_INVALID_ENUM no matter what command line settings are being used.
As for GL_MULTISAMPLE, it defaults to GL_TRUE when GDK_BACKEND=wayland GDK_DEBUG=gl-prefer-gl is passed on the command-line, and to GL_FALSE when only GDK_BACKEND=wayland is passed on the command-line but does apparently not depend on GDK_BACKEND=x11.
That solves at least my worries about anti-aliasing.
How do you know for certain that GTK is doing frame-rate synchronization automatically when GL_DOUBLEBUFFER is never GL_TRUE?
There’s no point in using GL_DOUBLEBUFFER because GTK is always “double buffered” (it’s actually using whatever buffer the EGL implementation is giving us, using swap control and buffer age extensions, so it could be using more than two buffers).
Under Wayland, GTK requests a surface from the compositor, draws on it, and then submits the contents of the surface to the compositor; under X11, the drawing happens on a surface.
You’re thinking of GTK 1.x or 2.x, back when people used a native X11 window and drew with GL straight on it; that hasn’t been the case since GTK 3 introduced GtkGLArea, and it’s definitely not the case with GTK4, which is itself a toolkit using GL or Vulkan to render its contents. Your GL rendering code must always be driven by the GTK rendering loop, on the surface it is given.
I already wondered how the edges of the GtkGLArea(s) related to the screen corner and the vertical retrace, but this explains a lot. Framerate synchronization is done systemwide by the Wayland server and not by the GtkGLArea, even when the request for GL_DOUBLEBUFFER returns a GL_INVALID_ENUM. The variable is of no importance these days.