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

[lcouka]

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

[DaveH]

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…

*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.

[lcouka]

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.

Many thanks,

[LiamG]

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.

[lcouka]

Yes, I built everything in release mode.

[olilarkin]

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 !

[DaveH]

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

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

Shadertoy

[olilarkin]

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

[lcouka]

I just did a really simple test.
A white square moving from the left to the right. with iPlug2 and Juce frameworks.

With Juce the animation is not fluent at all and the square seems to have spasms while moving.
With Iplug2/skia cpu rendering, those animations are quite fluid and smooth, I noticed some rare cases when it jerked, but with Juce it’s like 2 jerks per second, which is quite unsuitable.

It could be great if the juce team could look up at this issue…

Thanks,

[daniel]

TBH I made even more complicated animations that are running fluid.
So chances are you are doing something in your code that is not compatible with the way juce works or is buggy.

So without the code to replicate the issue it is probably impossible to comment.

Addition: Have a look at the DemoRunner: Browse demos -> GUI -> AnimationExample

[lcouka]

Well I just created a new animated project from the projucer, then added the following paint function

void MainComponent::paint (juce::Graphics& g)
{
    g.fillAll(juce::Colours::black);
    g.setColour(juce::Colours::white);
    g.drawRect(3 * getFrameCounter() % 400 + 10, 10, 100, 100);
}

Then building in release mode.

[xenakios]

I can reproduce the issue here with Juce 6, Visual Studio 2019 and Windows 7.

However, I wonder if the issue is because of using the getFrameCounter call to calculate the rectangle position…One should probably instead use a clock time difference calculation for that.

edit : Unfortunately, an initial test without using the getFrameCounter didn’t solve the issue. It still looks like some frames are “skipped”. I need to test a bit more, in case I did some mistake with the alternative implementation.

[daniel]

I was looking at the source (am on mac). The getFrameCount() is incremented in the timerCallback().
This could only be different from the clock, if the Timer is set so fast that it cannot finish.

May I ask what timer interval you set?
I would be surprised if a value below 100 (actually 30 should be ideal) makes those problems, but I might be wrong…

[xenakios]

The default is 60 timer callbacks per second. I also tested with 30, but that didn’t help.

I wonder, could Juce on Windows be doing some kind of “hidden” heavy processing occasionally in the GUI thread?

[daniel]

Very strange. Seems the timer accuracy is to blame then…
I have no idea, good luck!

[lcouka]

I tested back the IPlug2 version and now I get those “jerks” issue on it too, where before it was quite 100% perfect.
Honnestly I don’t know too much if it’s an issue of Juce or if it’s related to the OS itself, or even the screen.
Thanks for the help anyway I’ll invest.

[xenakios]

Maybe it’s some issue with hardware interrupts or something? I suppose more people on Windows should test this, so we could start to understand this issue. (On my part, I can say it isn’t the classic “turn off your WIFI”-issue, because this desktop PC I am on at the moment, doesn’t have WIFI. )

[anthony-nicholls]

When animating ideally you should never rely on the frame rate to do animations you should always calculate animations based on time otherwise it will behave differently on different machines. I can see the tutorial is using getFrameCounter(). I would suggest the tutorial is updated to prevent people making this mistake.

[xenakios]

I already tested that alternative approach, like I explained above. It didn’t help. The issue is apparently something that prevents the component painting from working reliably. It’s probably something in Juce’s Windows implementation that does something heavy in the GUI thread every 2 seconds or so, or a Windows system issue.

[anthony-nicholls]

@xenakios oh sorry totally missed that. How odd! To be clear you’re using the time since the app or animation started to calculate a position? It doesn’t surprise me much if the odd frame is missed but I wouldn’t expect it to be noticeable.