just think, JUCE 7 is guaranteed to happen because you guys will have to update JUCE 6 to support whatever Apple decides to go with in 2 years haha.
Very true. Lots of the graphics things we do, like slider animations, level meters, goniometer, spectrum analyzer, aren’t really possible/performant with the JUCE CoreGraphics or Software renderer. In our testing, basically anything that moved at ~60 fps needed to be OpenGL.
The very reason why I went with Juce is to get away from Apple’s redacting mania, and concentrate on creativity. It’s worked so far!!
Yes I agree Dave, I really value a layer of insulation from the froth generated by the capricious and sometimes selfrighteous behaviour we are subjected to coming from Apple.
As has been said a couple times, Vulkan on Windows/Linux/Android + MoltenVK on macOS/iOS is the future for (extremely) performant, portable graphics.
For JUCE’s use case, Vulkan’s design is especially useful. As is currently stands, JUCE’s OpenGL runs calls on a separate thread to keep latency down; by design, this is how Vulkan (also Metal and DX12) do work via manually managed asynchronous command buffers without requiring crazy multithreading anti patterns due to driver overhead.
If the team really wanted to get crazy with video backend code-sharing, the core scan line rendering loop could be written portably such that it could be used as either a Vulkan GPU compute shader (possibly eschewing a traditional rendering pipeline entirely) or as a CPU renderer for the software renderer.
That is, unless JUCE wants to keep chasing ever-changing proprietary APIs like Metal while they’re still in flux.
“Yea, I clicked the link, preparing to equip my Leather Armor of Technical Outrage, and after reading the details, this is about as mundane as it gets.”
Little ashamed to admit this described my reaction as well.
I really want to continue using Juce. Is there any way I can get any assurances that they’ll be a hardware rendering solution coming down the pipe for us at some point? I’m in the process on converting my old plug-ins over to Juce, and some of them currently use OpenGL quite extensively. Upsterero Pro, for example, is renderered entirely in 3D https://www.youtube.com/watch?time_continue=19&v=aCQiUx542EA
What have we said to make you insecure about that…? We don’t really think there’s any kind of urgent panic, as OpenGL will have to be supported even by Apple for at least a good few years. Over that time we’ll do what everyone else in the industry will do, and migrate to newer technologies. If you already have openGL code then you probably don’t need worry about migrating from it just yet.
I’m not panicking, I’m planning for the future.
It might be gone by next year, and I’m a one man dev.
No, it won’t be gone next year. Imagine how many thousands (millions?) of legacy games and apps will be bricked when openGL is removed.
Apple have deprecated many other APIs, but they always kept supporting them for at least a few years to give time for people to migrate, and GL is a particularly widely-used one where there’ll be pressure to keep it around for even longer.
That just tells me you have nothing planned.
If you feel like you need to have a replacement in place until next year, and you don’t trust that there will be a solution from JUCE, better start writing something now.
JUCE will not go out of business, just because Apple deprecates one of their many APIs.
Plus deprecating doesn’t mean removing (was mentioned before)…
Not this update anyway.
There’s nothing to plan.
At some point we’ll replace our GL support for the equivalent thing in Vulkan/Metal, which isn’t super hard to do, it’s basically the same principle, just a different API. Most people won’t notice the difference.
You’d think that the Federation could at least afford an Indie license to get rid of the splash screen.
But money doesn’t exist in the future…
At the rate we’re going, it’s 6:5 and pick 'em for the future itself, never mind money.
That said, I imagine OpenGL’s deprecation will be like Carbon’s deprecation; we’ll have a solid 4-5 years. Like Carbon, it is too intertwined in the workings of things.
Does this miss the point a bit though? If you’ve got code that uses actual OpenGL code (i.e. shaders etc.) then this doesn’t really have anything to do with JUCE.
You’d have to re-write all that code to use Metal or something else anyway?
Or are you simply asking about the
OpenGLRenderer class etc. which gives you the OGL callbacks and if there will be a Metal replacement for that?