I’m looking for some pointers on where to start/examples to refer to.
What I’m hoping to do is open a separate borderless window from my main audio plugin (i did it already for non-GL graphics) and render texture clip arrays and point sprite arrays (with source texture), ideally accelerated with Open GL.
I did this in the past in a game engine I wrote in C++ in order to make tilemaps and a particle effects class and used glDrawArrays (with vertex buffers and color array buffers) - but it not clear that would be supported in JUCE - all the examples I see show usage of shaders (which I would need to learn about and it’s not clear for me how I would use them to generate lots of particles for example).
I would use the JUCE graphics class preferably to not need to delve into the pain of Open GL, but from what I saw there’s no equivalent drawArrays/batch draw functionality, so it probably would not be efficient e.g. to use drawImage/set opacity/colour (set a colour filter on an image?) for every single particle/image clip when there might possibly be 1000s flying around the screen.
Or maybe glDrawArrays is just not the way to do it these days? - it shows up as deprecated for OpenGL-ES in my old game project.
I have briefly been looking at libcinder - which has some nice open gl abstractions including batch operations (although those appear linked to a default shader) - but I would rather stick with JUCE only.
Thanks for any pointers.
OK… so it turns out drawElements/arrays is still a thing in Open GL … and I’ve been digging into various threads and referenced back to Matt Tytel’s Helm VST code for an example on how to make a “OpenGLcomponent”/background in JUCE and there I followed his background/oscilloscope example and see how it’s linked to a set of simple shaders and attributes permitting passing parameters to the shader via the buffers… Thanks again Matt for sharing your project. Now I can see how I can add additional shaders and OpenGL components… what I’m still not sure is if I can overlay one GL component over another (e.g. to get multiple layers).
Now, my issue is that after implementing a separate open GL window/component and testing a dummy scope trace buffer (which is printing just fine), even after using a 20Hz timer set flag to minimize the number of open GL render calls, the CPU load on my app (with no audio processing enabled) goes from 5-10% to 40-50%+ (and profiler shows all the time is taken in the GL render calls) .
I’m wondering if this is linked to future deprecation of OpenGL on MacOS ? I’m on Mojave 10.14.13 with a brand new Mac pro 13inch (i5 16G ram) - “Intel Iris Plus Graphics 655 1536 MB”.
Even Helm, my original reference seems to overload the CPU (80% in release mode build with no sound playing), where I’m pretty sure it used to run with very little CPU overhead.
So, I wonder is this related to Open GL deprecation in Mojave? (I read something about glSwapBuffers being affected on one of this forums threads?)
(Note I’m using JUCE 5.3)
All of this is maybe not a huge issue because in the particular case the app I’m working on is only for Windows based machines, but my main dev machine is currently a Mac. I wonder how hard it will be to switch render code to Metal and if JUCE will support a similar API to the way it provides Open GL access.
I’d be happy to just use the JUCE API and hope that it maximizes use of GPU on any target platform, but as mentioned before, there doesn’t appear to be any native 3D/accelerated buffer operations wrapped directly by JUCE graphics classes, + I’ve been playing with shadertoy (webGL based shaders), and hope to bring over some shader code… more reading to do…
Quick followup - my plugin build with the same project/same test Open GL window is sitting around 4-5% CPU load in a Windows 10 NUC i7-7567U(3.5GHz)… seems much more inline with expectations.
In case anybody is interested - GL performance issues on Mac Mojave went away after I switched to using “defaultGLVersion” for the openGL context (in setOepnGLVersionRequired function)… case closed…