Yet another OpenGL renderer

[nikp123]

This is partly motivated by seeing how much I like the cairo system that I built. Unfortunately it's cairo, which means that the rendering is quite slow for something as intense as a visualizer. The current system, while more flexible than the last ones, is nothing in comparison to what cairo achieves.

My idea is the following:

xava main -> platform native window -> OpenGL main handle (via GLEW or EGL) -> OpenGL modules (emphasis on the s)

Implemented like this:

1. The main handle should be able to load multiple modules using arrays of structs and a global "OpenGL module handle" that exists in cairo as well. This will allow the modules to use the same resources as all other parts of the visualizer.
2. The main handle SHOULD handle the post processing shaders, because applying multiple post shaders basically makes no goddamn sense, you'll just get a corrupted/ugly looking image.
3. The main handle should initialize the mian OpenGL resources/variables and let the modules create their own uniforms and such.
4. The modules should draw to the same buffer using the FBO system already built, this way we ensure that the visualizer doesn't take hundreds of MB of VRAM, because creating a FB for EVERY single module is a memory hog and GPU hog. However this means that the modules themselves should be responsible for what they draw on the screen, aka. no module should overwrite the entire screen.
5. The post shaders should have standardized uniforms and optional ones enabled through the config.ini thing I've already built. This ensures that the resources NOT used by the visualizer don't end up calculated, saving on (already limited) resources.
6. Post shaders should demonstrate the power of filtering and what it can do to an OpenGL scene.
7. The individual modules should focus on keeping the logic to themselves and handle geometry in the shader itself (if possible), mostly because geometry shaders are not well supported except on newer graphics cards 2014+ (i know this may seem old, but people are still running bad PCs).
8. The modules should also share resources if possible: intensity value and other goodies. Perhaps a common feature flag (similar to how regions are handled by cairo)?
9. The main handle (AND ONLY THE MAIN HANDLE) should take care of clearing the FBO. The same as cairo.
10. Implement previous features that are now missing such as oscilloscope, artwork, kinetic... etc. through this system, if it ends up working.

[nikp123]

Of course I won't be able to do this overnight because that's quite a bit to go through, I bet this is going to be three times as hard as cairo is simply due to OpenGL's inherit complexity.

[nikp123]

For those interested the development and testing of this will be in unstable and ONLY when it works (or most of these things are completed) would it be merged into master.

[nikp123]

Related #14 describes my previous attempts/struggles of choosing an ideal system for something flexible enough as this visualizer.

[nikp123]

Still deciding whether a combined draw would happen (as this is a billion times faster than drawing on separate occasions), but then again, I'm reusing the same framebuffer so it shouldn't be that bad, I believe. But yeah, this greatly diminishes the massively parallel design of GPUs and may end up being a gigantic bottleneck, we'll see.

[nikp123]

The reason why I'm avoiding merging everything into a single draw call is the sheer complexity of the variables involved and also means that ONLY ONE shader may be used, which GREATLY limits the flexibility of the system and increases it's complexity/break-ability.

[nikp123]

also no regions as that would be just a waste on time on GPU's to do anyway

[nikp123]

status update:

1. is done
2. done
3. done
4. already use the same FBO, so it's stupid fast and efficient
5. not done, but likely not going to do it as well, because it's barely any cpu time to save
6. done by default
7. yep, this is also done
8. not done, see 5
9. yes
10. not done, yet

[nikp123]

wayland + EGL is borked for some strange reason on the first run, considering a reset hack :)