gl-spectrum: Add modern GL renderer and GtkGLArea support

[rsxrwscjpzdzwpxaujrr]

Closes audacious-media-player/audacious#1546

AFAIU gl-spectrum plugin using GLX is one of the blockers for transitioning to using wayland by default. Well, not anymore, because I implemented GL context creation through GtkGLArea widget. Unfortunately, there are no good ways to force GtkGLArea to create a legacy GL context, it only falls back to legacy context if creating a core GL context failed, and this plugin used only legacy GL functions for rendering. So I implemented a new renderer which uses modern GL functions. The modern renderer is not uploading the whole scene to GPU on every frame like the legacy one does, but uploads it only once and then uploads only the height map on every frame, which is used calculate the actual geometry in a vertex shader, which should make it faster. The context version is being checked in runtime and the modern renderer is used if requirements are met, if not it's just using the old one. The modern renderer is also used by default in the case of context creation through GLX and Win32. If everything works fine, GLX and Win32 GL context creation code can be safely removed to reduce unnecessary complexity, and it won't change the minimal required OpenGL version as we can always fall back to the legacy rendering.

I also want to note that with the modern renderer cool effects can be added in the future. For now it's just replicating the old one.

Please test in on Windows and macOS before merging, as I can't verify if it's working there (it should).

[radioactiveman]

Thanks for working on this. 👍 I'm looking forward to try it out when finding some free time.

AFAIU gl-spectrum plugin using GLX is one of the blockers for transitioning to using wayland by default.

The main reason for using XWayland by default is that the Winamp interface is unusable on Wayland, see #1560 for more details. Supporting the gl-spectrum plugin on Wayland is of course still beneficial.

Questions from a first quick look:

• We already require GTK 3.18 if GTK3 is enabled. And these versions depend on libepoxy. Maybe we can simplify the code and build system checks if we say "always use the modern renderer for GTK3"?
• glm however would be a new dependency. Is it possible to avoid this library?

[rsxrwscjpzdzwpxaujrr]

The main reason for using XWayland by default is that the Winamp interface is unusable on Wayland

Can't we use XWayland only when using the Winamp interface then?

Maybe we can simplify the code and build system checks if we say "always use the modern renderer for GTK3"?

The modern renderer and the GL context creation through GtkGLArea are 2 separate things. If you meant "always use context creation through GtkGLArea for GTK3", I can do it and it would simplify the code without any drawbacks. If you actually meant the modern renderer, I can also do it, but it won't make sense, it would increase the minimal OpenGL requirements without simplifying anything. Modern renderer's minimal requirements are OpenGL 2.1 with ARB_vertex_array_object extension (which became part of the standard since OpenGL 3.0) or OpenGL ES 3.0. We can go even further and always use the modern renderer even with gtk2, if that's what you want, in that case we could remove the legacy rendering and simplify the code. The modern renderer doesn't care how the context was created.

glm however would be a new dependency. Is it possible to avoid this library?

I can do it if that's what you want. In OpenGL core context matrix manipulation functions were removed and people need to implement the matrix math themselves or use something like glm. glm is a header-only dependency hence it's only needed in build-time.

[rsxrwscjpzdzwpxaujrr]

I found a performance regression with GtkGLArea after docking the plugin, and the performance stays poor even after undocking it back until you restart the app. GTK3 seems to be copying the rendered image back and forth instead of directly displaying it on the screen after docking the plugin.

[radioactiveman]

Audacious 4.6 no longer enables Xwayland by default for the GTK/Qt interface. Therefore making the plugin compatible with Wayland became more important now.

Have you found a solution to fix the performance issue? Are you interested in finishing your PR?

[rsxrwscjpzdzwpxaujrr]

The PR is pretty much finished, I can resolve the conflicts and it'll be ready to be merged if you're. The performance issue is due to how GtkGLArea in GTK3 is implemented and I don't think it's something that we can fix. We can

1. Always use GtkGLArea on GTK3 and keep GLX context creation only for GTK2 to keep the code clean (the way it's currently implemented in the PR, but no code is removed and you still can get old context creation with -DUSE_GTKGLAREA=OFF)
2. Use GLX on X/Xwayland and WGL on Windows and keep GtkGLArea on Wayland. The code can be changed do to determining in runtime whether to use GtkGLArea or GLX/WGL instead of compilation flags like it's currently in the PR.

Which way do you want me to proceed? The performance regression is negligible and probably will be noticed only on pre-2010 tech.

Also, there are two renderers now, as we can't ask GTK3 to give us legacy OpenGL I created a renderer working with a more modern OpenGL. Which way do you want me to proceed?

1. Keep both renderers, the plugin will fall back to the legacy one when it can't run the modern one. (This is how it's currently implemented in the PR)
2. Get rid of the legacy renderer entirely to keep the code clean and use the modern renderer in both GTK3 and GTK2, the downside is that some pre-2008 tech won't be able to run it anymore.

Also, are you sure that you want me to proceed with getting rid of the glm dependency? It's a header-only dependency. If you are, I will get rid of it.

I'm not comfortable with making these decisions myself as this is not my project so I'm waiting for your response to proceed.

[radioactiveman]

My suggestion would be:

• Always use GtkGLArea with GTK 3, no fallback -> get rid of USE_GTKGLAREA completely
• Keep the old renderer for GTK 2 only, do not use the modern renderer for GTK 2

Then it probably would make sense to just split the plugin into two implementations. One for GTK 3, and one for GTK 2. Which one gets compiled can be decided in meson.build.

This makes the code much more readable. It already has too many ifdef's and with your proposed changes this gets even worse.

Could you please prepare a minimal GTK 3 only implementation to see if this is feasible?

Regarding glm: How much custom code would be required when we want to avoid glm? If it is let's say ~100 lines, I would be in favor of that. But I can't estimate that yet.

Thanks.