Interesting. When I move the allowed-apis from the xml file to the “realize” callback, I get that both APIs are allowed, but I don’t understand how to choose one. I have yet to find out what to do if the system doesn’t offer me the one I want.
If I try to:
gtk_gl_area_set_allowed_apis(glwidget , GDK_GL_API_GLES);
The response is “Unable to create GL context” written where the GL widget is supposed to be. I guess I am not doing it correctly.
Have you tried to call gtk_gl_area_set_allowed_apis() before GlArea is realized? I.e.
GtkWidget *area = gtk_gl_area_new();
If (GTK_IS_GL_AREA(area)) {
g_print("< GL API: %d\n", gtk_gl_area_get_allowed_apis(GTK_GL_AREA(area)));
gtk_gl_area_set_allowed_apis(GTK_GL_AREA(area), GDK_GL_API_GL/*GDK_GL_API_GLES*/);
g_print("> GL API: %d\n", gtk_gl_area_get_allowed_apis(GTK_GL_AREA(area)));
}
The check on the return value is pointless: constructors can only return a valid instance, never NULL or something that does not match the type.
The check on the return value is pointless: constructors can only return a valid instance, never NULL or something that does not match the type.
rationales to write it in that way:
- highly unlikely, but in g_object_new there’s still a path with NULL in return (if I’m not mistaken)
- if that’s used in a more common way (not just two sequential lines), I’d prefer be sure there’s not mistyping somewhere
No, there isn’t.
That’s not how things work.
Don’t add unnecessary type checks: they may be cheap when all things are considered, but they are not free.
Yes. That appears to be the only thing that does not return a direct error (assert).
Is this “never NULL” assured for all gtk_*new*() gdk_*new*() g_*new*() functons?
It’s for everything that creates a new GObject instance: g_object_new() cannot return NULL. Only objects that implement the GInitable and GAsyncInitable can have constructors that return NULL, but they also take a GError for that particular case, and their constructors are really g_object_new() + g_initable_init() in a trenchcoat.
Additionally, all allocator functions—except those with _try_ in their name—inside GLib will assert() if the system allocator returns NULL, as GLib explicitly does not handle OOM conditions (and it really doesn’t matter on systems with overcommit like Linux).
Thank you for details.
(Assuming direct alloc/assert are handled in system or in libs, beside of that)
If I want to get clue by new() function name declaration, can it be said that all _new*() functions with the exception of _new*(.., GError** error) are assured not NULL?
Now I’ve tested 4.14 and 412 under the same nvidia dirvers. 4.14 gives me only GL ES 3.2, 4.12 OpenGL 4.6. How is it possible that such a significant change is in a point release? This is what Torwalds is talking about. Linux desktop is a nightmare.
Do I have to permanently downgrade to 4.12 to be able to get OpenGL 4.6?
Because that’s how GTK has always worked: the major version is for API changes, not implementation ones.
The fact that GTK internally uses GLES doesn’t really matter: most drivers support both GL and GLES, and application code can create their own context. It seems that your nVidia driver is having issues with that.
But I only changed from 4.12 to 4.14, no reboot between, and then I cannot get to use OpenGL 4.6 anymore. How can the driver all of a sudden have a problem with when the only thing I changed was gtk (through an upgrade)? This makes no sense.
If GTK always has made functionality changes in point releases then this is clearly a toy project. How can you test anything that relies on it, especially when so much of the functionality has to be digged out of the source (I believe those are pretty much your own words).
I’m beginning to realize I;ve thrown away 3 years of development into the wrong toolkit. At least I now know the program will never be released for linux, which pretty much breaks my heart.
What has a reboot got to do with anything?
GTK 4.14 introduced a new default GPU-based renderer that prefers GLES to GL: NEWS · main · GNOME / gtk · GitLab
The GL driver you are using hasn’t changed; as I said, GTK prefers GLES for its own rendering, but drivers such as Mesa allow you to create GL and GLES contexts at the same time. Evidently, the nVidia driver that you are using has issues with that. It’s a bug—in the GL driver, or in GTK—but it has nothing to do with GTK preferring GLES.
Yes, it makes no sense if you have no idea about the changes in GTK; but those changes happen for a reason, and it’s really up to you to understand the implications. Otherwise, we would not publish a NEWS file with all the changes that happen during a development cycle.
Additionally, the fact that GTK prefers GLES can be handled by applications themselves: after all, your application must be able to deal with:
Adding support for GLES isn’t a large change, considering that both modern GL and GLES tend to converge.
The API that GTK provides to select the version of GL/GLES, and the allowed API, exist at the pleasure of the GL implementation that is available on the system that runs the code; there’s no guarantee that the GL implementation will support GL, or GLES, or both; or that it’ll support the version of GL/GLES that you’re asking. You already have to code defensively against that. If you’re only supporting GL and not GLES, then getting back a GLES context would require adding your own error handling.
Okay, I understand your frustration and lack on knowledge about the development of GNOME and GTK, but can you please avoid spewing value judgements on things you have no understanding? Because that makes it unbelievably easy to block you from this forum.
That’s entirely your choice.
I realize this is my last post, but:
Yes, it makes no sense if you have no idea about the changes in GTK; but those changes happen for a reason, and it’s really up to you to understand the implications. **Otherwise, we would not publish a NEWS file with all the changes** that happen during a development cycle
The joke in Hitchhiker’s guide about Vogons building the intergalactic motorway, wondering why earthlings are complaining was not lost on me. With time, I’ve learned that this is actually not a joke.
Okay, I understand your frustration and lack on knowledge about the development of GNOME and GTK, but can you please avoid spewing value judgements on things you have no understanding? Because that makes it unbelievably easy to block you from this forum
Yep, that’s the way to do it. Feel free.
Regards
Did you try to set GSK_RENDERER=gl for your software?
On my old but still perfectly fully working desktop (around 2007), the new default ngl backend is mostly unusable. Switching back to the old gl backend solves the problems, as advised by the GTK team for such hardwares.
Yes, I did try that. Had no effect. I was able to fix some things by small changes in the geometry shaders but, In any case, I had to stop developing on Linux. I cannot release a software, not knowing if it will break after an upgrade. Impossible to test.
I wish I had the programming muscle to do what blender does, but I don’t. It seems to be the way to go if one wants control and predictability.
Happy to hear you found a way around your problems.
GTK, and free softwares in general are a moving target. If you don’t want to spend your time trying to catch the train, flatpak may be a good solution to distribute your software.
As a user, I don’t really like softwares that lag behind, but targeting and sticking with gnome runtime <= 45 for your software may solve your problem. @ebassi may confirm.
Ps: it doesn’t mean that converting an old project to flatpak is easy 
This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.