Example without GtkApplication about glarea-example

[anderflash]

For the first problem (single GtkWindow and GtkGLArea), I got it working.
Now I need to see whether the solution is working in my home notebook.

[ebassi]

GTK+ creates OpenGL 3.2 core context profiles by default. Starting from GTK+ 3.20, GTK+ will try and fall back to legacy context profiles if core ones are not available; you can query whether the GL context is in legacy mode by using gdk_gl_context_is_legacy().

[Photon89]

For the first problem (single GtkWindow and GtkGLArea), I got it working.

@anderflash Could you please elaborate, maybe give some relevant code lines? I'm trying to port an initially GTK+ application to GTK3 and only get a black background. Unfortunately, my experience with GTK and OpenGL is just what I learnt during the last few days trying to do the port, so I don't feel well prepared to bring GtkApplication into the game... Thanks!

[ebassi]

GtkApplication has nothing to do with GL, so it's not a factor. It's just a fancy way of setting up a singleton state object, initialising the toolkit, and spinning the main loop. There's literally no difference between calling gtk_init() and gtk_main() yourself. Having said that, you are strongly encouraged to use GtkApplication for two reasons:

• it's idiomatic to GTK
• it's forward compatible with GTK4

I'm not going to modify the glarea example to be non-idiomatic, sorry.

If you're getting a black background with GtkGLArea it might mean a whole host of things: you may be using invalid GL commands; you may be setting up the state wrong; you may have forgotten to set up the default VAO; you may need to call glFlush() to ensure that your command pipeline is completed on the GPU; or your GL driver may be broken. By itself, GTK3 doesn't do much with GL: it sets up an FBO for you to draw into, and then it will take the FBO's backing texture and draw it at the right time in GTK's frame loop.

[Photon89]

Thanks for your explanations! I know how you feel, I also hate it when people insist on doing things in a bad way. 😃 The reason why I want to stick to the old fashioned way is that I try to port existing code with as few changes and as little effort as possible. Also, consider my background: I never coded in C so far (just had two one week introductory courses in C++ 10 years ago), never worked with GTK and OpenGL. Just had some spare time and thought, I'd use my "use the search engine" skills and see how far I get trying to port an app from 2001 to GTK2 or even GTK3. If I were to write a new app from scratch, I'd do exactly as you propose: Read the docs and do it the proper way -- but this is not how the situation is, unfortunately... I could already make it compile and run with GTK2, but the step to GTK3 is harder: It compiles and runs, but the OpenGL widget stays black.

you may be using invalid GL commands

I didn't change anything from the original GL code which works with GTK+ and GTK2.

you may be setting up the state wrong

Could you please elaborate on this? Is this something GL related or rather something involving interaction between GL and GTK?

you may have forgotten to set up the default VAO

This sounds purely GL related, so I hope, this is not the issue.

you may need to call glFlush() to ensure that your command pipeline is completed on the GPU

Yup, did that.

or your GL driver may be broken

As it works on GTK2, probably this isn't the reason.

Basically, I kept all the GL code which is working if compiled with GTK2, only had to remove the gtk_gl_area_swap_buffers() call on some occasions, because this function is not available in GTK3. I don't understand that well what it is doing exactly, how to do the same in GTK3 and whether there is a simply substitution for it which I wasn't able to find, or significant parts of the code need to be changed with the GTK2 -> GTK3 transition. I read your article on this topic and it sounded to me like the latter might be the case, but I try to stay optimistic...

Edit: I got some debugging output which might help to pinpoint the issue:

$ GDK_DEBUG=opengl ./src/lightspeed 
Building 1x1x1/6 lattice...done (600b+840s vertices, 1280b+1504s indices).
Gdk-Message: 12:08:37.494: GLX version 1.4 found
 - Vendor: NVIDIA Corporation
 - Checked extensions:
	* GLX_ARB_create_context_profile: yes
	* GLX_EXT_create_context_es2_profile: yes
	* GLX_SGI_swap_control: yes
	* GLX_EXT_texture_from_pixmap: yes
	* GLX_SGI_video_sync: yes
	* GLX_EXT_buffer_age: yes
	* GLX_OML_sync_control: no
Gdk-Message: 12:08:37.495: Creating GLX context (version:3.2, debug:no, forward:no, legacy:no, es:no)
Gdk-Message: 12:08:37.495: Creating GL3 context
Gdk-Message: 12:08:37.526: Realized GLX context[0x55b7ab2bc398], direct
Gdk-Message: 12:08:37.526: Creating GLX context (version:3.2, debug:no, forward:no, legacy:no, es:no)
Gdk-Message: 12:08:37.526: Creating GL3 context
Gdk-Message: 12:08:37.527: Realized GLX context[0x55b7ab154568], direct
Gdk-Message: 12:08:37.527: Making GLX context current to drawable 73400350
Gdk-Message: 12:08:37.640: OpenGL version: 3.2 (core)
* GLSL version: 1.50 NVIDIA via Cg compiler
* Extensions checked:
 - GL_ARB_texture_non_power_of_two: yes
 - GL_ARB_texture_rectangle: yes
 - GL_EXT_framebuffer_blit: yes
 - GL_GREMEDY_frame_terminator: no
* Using texture rectangle: no
Resized camera 0 to 578x416
Initialized viewport 0
Gdk-Message: 12:08:37.688: Making GLX context current to drawable 73400349
Gdk-Message: 12:08:37.692: OpenGL version: 3.2 (core)
* GLSL version: 1.50 NVIDIA via Cg compiler
* Extensions checked:
 - GL_ARB_texture_non_power_of_two: yes
 - GL_ARB_texture_rectangle: yes
 - GL_EXT_framebuffer_blit: yes
 - GL_GREMEDY_frame_terminator: no
* Using texture rectangle: no
Gdk-Message: 12:08:37.694: Making GLX context current to drawable 73400350
Gdk-Message: 12:08:37.695: Making GLX context current to drawable 73400349
Gdk-Message: 12:08:37.695: Making GLX context current to drawable 73400350
Gdk-Message: 12:08:37.695: Making GLX context current to drawable 73400349
Gdk-Message: 12:08:37.708: Flushing GLX buffers for drawable 73400349 (window: 73400323), frame sync: no
Gdk-Message: 12:08:37.713: Flushing GLX buffers for drawable 73400349 (window: 73400323), frame sync: no
Gdk-Message: 12:08:37.714: Making GLX context current to drawable 73400350
Gdk-Message: 12:08:37.726: Making GLX context current to drawable 73400349
Gdk-Message: 12:08:37.743: Flushing GLX buffers for drawable 73400349 (window: 73400323), frame sync: no
...

[ebassi]

If you were using GL with GTK2 you have been doing so using ancillary libraries written 20 years ago, like gtkglarea or gtkglext; those libraries are fundamentally different not only from how GL support is implemented in GTK3, but also how GL code should be written in 2022. Both gtkglarea and gtkglext used a native windowing system surface to draw on, instead of an FBO; both gtkglarea and gtkglext used legacy GL 2.1 or earlier GL context creation; both only supported legacy GL.

GTK3 (and GTK4) default to core GL 3.2+ context profiles, and disable deprecated/legacy GL support—unless the GL driver only supports legacy GL, in which case you'll get a GL 3.0 context.

This means two things:

• you cannot compare what GTK2 + additional libraries were doing with what GTK3 is doing. They are two fundamentally different toolkits, with different integration with GL
• you cannot run GL code unmodified from GTK2 + additional libraries with GTK3

You will need to port your GL code to the 3.2+ API model in order to port to GTK3.

If you have questions about using GTK3, instead of using the issue tracker of an example, I strongly recommend using GNOME's Discourse instance.

[Photon89]

I see, thanks again for you explanations! Just one last question: Is there a possibility to get compiler or runtime warnings on GL commands which are not supported in GTK3 any more? As in my case the compiler tells me nothing and there is also no output on runtime, so I'm having a hard time to figure out which commands are still fine and which are not supported any more...

[ebassi]

That depends entirely on your GL driver: GTK does not have anything to do with that. Mesa on Linux has environment variables controlling the debug verbosity.

[Photon89]

This looks like it will help a lot, thanks!