
It probably still doesn't work on some systems running GTK earlier than 3.22 and I could use some help with that.
I'm putting bits on the screen using OpenGL (because typically that is the fastest way to do so), and the code is written for OpenGL 1.3, AKA "Real GL" (because that's what I had already, and because every Linux system supports it and will until the end of time).
However, apparently GtkGLArea has other notions, and on some systems, creates a GL context that only works with... OpenGLES 2.0? OpenGL 4.3? Who can tell. If I set the "use_es" flag on the GtkGLArea, things work on those systems, but that flag was only implemented in GTK 3.22.
So, two requests:
- If you have a pre-3.22 system, and it is not working, and you can figure out how to make it work, please let me know. Possibly this involves the "create_context" callback in window.c, but I dunno.
- If you would care to rewrite my dead simple GL code that just blasts a texture onto a quad in such a way that those failing systems are happy with it, please let me know what you did. I'm guessing this means using GLSL, but since I don't know what version of the OpenGL spec is being targeted by GtkGLArea, I'm not sure.
The failing systems are absolutely capable of running OpenGL 1.3 code, because they are all capable of running XScreenSaver and that's what it uses, so GtkGLArea's requirements are baffling, particularly that they shift like the sand depending on.... distro? Video card? Who can tell.
Oh yeah, some other stuff:
Is there a way to tell GtkWindow "draw on this X11 Window ID instead of creating your own"? Asking for a friend who is a screen saver.
Is there a way to tell the compositor to respect the alpha channel of the OpenGL frame buffer, so that (as in the Mac version) the clock can have a translucent background while the foreground digits are fully opaque?
By the way, here's a rundown on the various versions of OpenGL, ask me how I know:
OpenGL 1.0 1992: | Standardized version of SGI's "GL" |
OpenGL 1.1 1997: | Improved texture support |
OpenGL 1.2 1998: | Nothing interesting |
OpenGL 1.3 2001: | Multisampling, cubemaps |
OpenGL 1.4 2002: | Added auto-mipmapping |
OpenGLES 1.0 2003: | Deprecated 80% of the language; fork of OpenGL 1.3 |
OpenGL 1.5 2003: | Added VBOs |
OpenGLES 1.1 2004: | Fork of OpenGL 1.5 |
OpenGL 2.0 2004: | A political quagmire, added shader language GLSL 1.1 |
OpenGLES 2.0 2007: | Deprecated 95% of the language; fork of OpenGL 2.0; GLSL 1.20 |
OpenGL 3.0 2008: | Added FBOs, VAOs, deprecated 60% of the language |
OpenGL 3.3 2010: | OpenGL 3.3 and OpenGL 4.0 released concurrently; 3.3 has GLSL 3.30, but 4.0 has GLSL 4.00 |
OpenGLES 3.0 2012: | Same as WebGL 2.0, but has GLSL 3.00 |
OpenGL 4.3 2012: | Superset of GLES 3.0, but has GLSL 4.30 |
Anything later: | My ignorance is blissful. |
It works, huzzah. On an Ubuntu 20.04 with intel and/or nvidia graphics (via nvidia prime). GTK is 3.24 so I can't shed light on that side of things though.
Thank you.
It just works™
F36
nVIDIA 515.65.01
🍾 🥂
Success for me.
OS:
Graphics:
Compiler:
GTK version:
Configured with:
Compiled with no warnings (using GNU make; BSD make is famously snooty about syntax). Everything is installed under /usr/local/xdaliclock as expected. The schemas are installed under /usr/local/xdaliclock/share/glib-2.0/schemas, which of course is not searched by default at runtime. To get around this, I set the following environment variable:
An alternate solution seems to be to put the xdaliclock-specific files under ~/.local/share/glib-2.0/schemas .
Once one of those two things is done, it seems to run fine, and is very trippy. I can bring up the configuration menu and everything.
Sorry, I don't have an easy way to test with older GTK3 versions.
Pre-3.22, GtkGLArea never tries to create a GLES context. But, then and since, it does prefer core GL contexts over compatibility. I think (have only read the code, not tried it) you want to do
The way to get the compositor to respect the alpha channel is to create your window on a visual that has an alpha channel, ie one where depth is 32 not 24.
Well, except that the source I've seen for that function says "versions less than 3.2 are not supported". And some users (but not all) get that as an error message.
Is there any sample GTK code out there that successfully does this? I looked but did not find.
That's gdk_gl_context_set_required_version, which is not what I said.
Erk, apologies for the thread break. To the gtk question, I don't have sample code at hand, but gtk4 does away with non-RGBA windows altogether, and the 3-to-4 migration guide suggests the way to prepare for that is:
after you've created the GtkWindow.
Hmm. Well, on my emulated Debian 11.4 system, doing either gdk_gl_context_set_required_version or gtk_gl_area_set_required_version results in "invalid enum" errors, and gtk_gl_area_set_use_es makes it work.
For number 3, I have discovered gdk_x11_window_foreign_new_for_display which lets you create a GdkWindow with a pre-existing X11 Window backing it; and gtk_widget_set_window which allegedly allows you to change the GdkWindow that is backing a GtkWidget or GtkWindow. One would hope that you could use this to cause a GtkWindow to render onto a pre-existing X11 window, but I have not been able to make that work.
The top gist at https://gist.github.com/mmozeiko/2401933b1fa89e5d5bd238b33eab0465 seems to work on my system. It gives the X11 Window to a GdkWindow with that API call , and then does a gtk_widget_set_window(widget, (GdkWindow*)user) during a "realize" callback, and then does things like XCreateGC() and XDrawRectangle() using the original X11 Window.
Hmm, almost there! That test does work for me, but when I try to translate it to the Gtk3 "GApplication / g_application_run" style, it stops rendering sub-widgets.
Hey, if anyone can figure out how to make this go when you change the #if 0 to 1, lemme know... Without the X stuff, I get a white window with a menubar, a label and a button. With, I get a black on black window, with a menubar that shows up if you click where it should be, and no label or button. So it's like half working?
I have not yet solved the problem, but I will leave my work here in case it helps someone. I decided to see if even "normal" external Gdk windows could be supplied to GtkApplications, and it took some doing but it works. I isolated the changes to make A/B testing a little easier. I plan on poking at differences between the results of the two GtkWindow-providing functions, to see what might be tripping things up. It's also interesting that the make_gdk_window() version doesn't produce any Glib warnings, but the make_x11_window() version produces several ugly-looking ones that have resisted my efforts at interpretation.
Yeah, I'm also getting nowhere with this. I've been reading through the GTK3 source and the differences between what make_gdk_window and gdk_x11_window_foreign_new_for_display do are not obvious. Those "frame clock" warnings suggest that the window does not have one of those, but there is no public setter method as far as I can tell.