Juce constantly freezes and is not suitable for animations (both native OpenGL and software renderer)

Hello,
Creating a new animated project via the projucer and copying the paint implementation from https://docs.juce.com/master/tutorial_animation.html
Give you the right result :
https://docs.juce.com/master/tutorial_animation_screenshot3.png

BUT

The animation is not fluent at all and gives the feeling to get repeatedly freezed which is absolutly horrible for me as a user point of view.

So I did the same with open GL thinking the only way to get proper animations in Juce was to do the painting by yourself. Unfortunatly, running shaders into Juce gives you exactly the same result, with quick freezes which makes it totally unsuitable to do any kind of fluent animation movement. While in shadertoy.com or vertexshaderart.com this same shaders are running smoothly without effort.

A really wonder if it’s only on my machine, if it’s me who is doing something wrong, or it’s just because those freezes are too subtile and people don’t care.

The fact is, for now, I didn’t find any way to just do one simple fluent animation in Juce.
It’s not something new, it’s something I always experienced with Juce.

Cheers,

Setup : Windows 10, i7-9750h, Juce 6.0.4

With my experience with OpenGL animation and Juce, while developinng my plug-in, UpStereo Pro : https://www.quikquak.com/ (I designed the display shader in Shadertoy, which was a lot of fun!)

You have to remember that it’s a plug-in and you have a lot of competition for graphics. You’re sharing the rendering with possibly over a dozen other things, all wanting the #1 slot!

Only have one OpenGL context, and calling the other renders when the main ‘renderOpenGL’ is called, not forgetting to set the viewport in each. This sped things up nicely for me with multiple panels.
I did this because I’ve had hang crashes in the swap buffers in Cubase and Logic when using multiple contexts. Especially recently.

If you still have slow-downs then set setContinuousRepainting to false, and openGLContext.setSwapInterval(0) using a timer to call repaint() at about 30 frames a second to stop getting in the way of the host rendering and other plug-ins etc. (It’s also a reasonable frame rate and a good compromise in most situations) - it reduced judder and felt a lot smoother when I tried this. You could try using 60 fps of course, but that depends on many things I don’t know about what you are rendering.

A another answer would be to use Metal and the latest DirectX, but that’s another story… :slight_smile:

*edit - I wasn’t aware of the AnimatedAppComponent. You could use that instead of using a timer like I suggested above, it’s pretty much the same thing.

3 Likes

Hi Dave,

Thanks for the advice about having a single openGL instance.
Currently I’m looking at other alternatives like IPlug2 that claims to be 60 fps ready and embeds the Skia graphical backend from google, It runs fine on my side and I need to benchmark it to compare it with the Juce performances drawing, how the text renders, how the antialias performs, cpu perfs, etc…

Also I really like your plugins especially the pitch shifter one, glad to know UpStereo Pro animation has been done with a shader. :slight_smile:

Many thanks,

1 Like

I’m no expert at animations, but are you compiling in debug mode? If so, try it in release mode and see if it’s any better.

Yes, I built everything in release mode.

that is a really cool use of a shader in a plugin @DaveH, but you should have called it “eye of mordor”. I’m probably not the first to say that !

2 Likes

@olilarkin Hey thanks, yeah it means you only need 2 polygons, as the GPU can ray-march whole scenes in the fragment shader alone :grinning: GPUs are insanely fast, even one’s on Apple machine’s these days! :innocent:

Here’s an “eye of mordor” I did seven years ago(!)… (it might be buggy on iOS as it only supports WebGL1)

2 Likes

sauron! I remember seeing your stuff on shadertoy. great work!

1 Like