Getting there!

OpenGL output under Linux! About fucking time.

Was it a ride to get there, though.

As I explained in a previous post, the first attempts with a GtkGLArea were a trainwreck. GtkGLArea is nice and all, but it's really limited in how much control you have over rendering, compared to, say, the Windows equivalent (get a GL context for any HWND and do whatever you want).

For one, GtkGLArea provides no control over its GL context, other than "make context current now". No way to unset the current GL context, which is important in melonDS. Even though all the rendering is done in the emu thread, we do need to unset the GL context at times, because when changing video settings we do reconfiguration from the UI thread, and said reconfiguration involves GL calls.

But, well. You may already know that GTK isn't thread-safe. As such, GtkGLArea really isn't designed to be used outside of the UI thread, or outside of one particular way. So, unless we rewrote melonDS's rendering system, this would have never worked. Besides, the emu thread is distinct from the UI thread for a reason -- I'm reluctant to having any work that may affect emulation done on something as uncertain as the UI thread.

So, I began researching.

And, now, the melonDS company proudly presents the result of all that research: the DIY GL area.

Basically, I decided to directly use GDK's GL context API to get the level of control I needed. With this, you don't need a specific widget type, you can create a GL context from any GdkWindow (which you obtain from any realized GTK widget). You can then use the function gdk_cairo_draw_from_gl() to draw your OpenGL output to the widget.

So I'd basically replicated the GtkGLArea, which in itself simply wraps around the aforementioned API. It's a simple framebuffer that you point OpenGL to, and that you resize as your widget gets resized.

There is still one issue: when using GL contexts, GTK will issue GL calls when rendering the area widget, and will do so internally, before calling the widget's draw handler. This is a problem if these calls are issued while melonDS's emu thread is also issuing GL calls. To avoid this, I had to resort to some trickery: melonDS's GL calls are wrapped in a critical section, and I used a custom GDK event handler to wrap any GTK draw events in that same critical section, before GTK starts issuing GL calls. This way, only one thread can be doing its GL work at the same time, and we avoid potential shitshows.

In reality, this took a while to get working, but, here we are. OpenGL output under GTK, stable and fast, and without needing to rewrite melonDS's rendering system.

Oh also, this supports hi-DPI! Provided you have a good GPU and not too shitty drivers, you get hi-DPI OpenGL graphics, and that sure does look nice.

There are still some tidbits to fix (like, some bugs in fog that appeared after I had to made a fix for Intel drivers), but we're way close to a finished product here.

I will also try to see if I can make hi-DPI work under Windows, too.
Niklink says:
May 31st 2019
Congratulations! Can't wait for the 0.8 beta!
Branchus says:
May 31st 2019
I’ll definitely try the 0.8 beta
Great work
Zinx says:
May 31st 2019
Shitty drivers - Intel/AMD?
I guess.
Tsu says:
May 31st 2019
" Shitty drivers - Intel/AMD?"

Idk if it's still the case, but Nvidia's Linux drivers has a bad rep and AMD's Open Source Linux drivers are better than Windows ones. (especially for OpenGL)
Me says:
May 31st 2019
Great work, cant wait for release so its ported to N.Switch
MelonMan says:
May 31st 2019
Can't wait for 0.8
A dragon says:
May 31st 2019
Nice to hear it. I'm kind of hoping it will be possible to use an analog stick as a stylus in the next release, but it's nice to hear you got this working on Linux since that increases accessibility as Linux distros like ZorinOS, LinuxMint, Ubuntu, etc. are free and can be installed as a replacement OS for people who want something different.
nine says:
Jun 1st 2019
this is sick, can you file a bug against GTK to get the better GL context mainlined? last time I tried gl rendering it broke me.
Arisotura says:
Jun 2nd 2019
not really a 'better GL context' -- for most purposes, GtkGLArea is perfectly good, just not for melonDS
Post a comment