GPU supported UI rendering in 2020

Two of our apps using JUCE have been out for about a year now. Currently they’re macOS only but we’re just working on a Windows release.
The apps do video playback and they rely heavily on OpenGL for the rendering engine part.

We’re also using JUCE’s OpenGL supported drawing of the UI as this made a huge difference compared to non-GL drawing especially for smooth scrolling in tables and our media timeline.

We had a lot of trouble at the beginning to set this up correctly in combination with our own OpenGL based rendering pipeline. But it worked fine for all but very few users in the end.

I’m now getting more and more issue reports with weird UI glitches in the latest update of Mojave but primarily on Catalina so I’m thinking about getting rid of OpenGL altogether but I’m not sure what the best approach is at this time.

Is moving over to Metal the right choice at this point?
What about MoltenVK? As it’s developed by Khronos I’m assuming it’s supported well but is anyone using it and can share actual experience?
I know that you can do work in Metal and draw the result in an OpenGL render view but does the same work for MoltenVK/Vulkan?

What’s the current status of JUCE UI rendering?
Are we going to see a Metal/Vulkan/MoltenVK based UI renderer anytime soon?

Thanks in advance!


Can anyone from the dev team maybe share his thoughts on the topic? @t0m? @jules?
I’m sure I’m not the only one interested in this. Thank you!


An easy solution for fast smooth animations, repainting without interception from message thread, wether GPU or CPU based, stable to use inside plugin GUIs, multi-platform, is also my #1 feature request for JUCE.


Rendering performance was the #1 request from a lot devs…


We’re experimenting with new rendering approaches at the moment, but we don’t have anything ready in the near future. The first thing to emerge is likely to be a Metal renderer followed by Vulkan. I’ve had a go with MoltenVK but providing this in a framework like JUCE is pretty cumbersome.


Are there any easy ways to ease up the CPU usage of displaying Path instances with lots of points? Think Goniometer or Histogram…

Thanks @t0m for the feedback!
I haven’t had a look at MoltenVK, but can you outline why it would be cumbersome to integrate it in JUCE? Many dependencies?

Building it yourself is a pain, and we don’t want to require a binary component. Even once you’ve built it there’s some non-trivial config that needs to happen too. If you’re an experienced software dev then you’ll be able to work it out eventually, but for people just starting out with JUCE the experience would be horrible.


any updates on this?


are there any updates @t0m ?


We don’t have anything very interesting to share - we’ve been concentrating on accessibility support for the upcoming 6.1 release.


One trick I’ve used before is to keep track of the curve steepness and use less points if it nears a straight line. It’s easy to do, with a simple dot product between the adjacent points, and it saves a surprising amount of rendering time with waveform and shape drawing, and you really don’t see any difference.

As Juce is using a horizontal scanline render approach for Paths, slowness mostly comes from paths that have lots of intersections with horizontal lines. It can help to split such paths into multiple vertical stripes or you can turn those paths 90 degrees, render to an image and render the image turned back 90 degrees. Unfortunately, many graphs in audio do have lots of these intersections - like audio waveforms or spectral graphs.