Juce8 Animator unnecessary repaints?

General JUCE discussion
1

Hey there

Curiousity got the better of me and I got looking at the Animator module again. In the blog article it mentioned this which I thought was a bit alarming:

When to call repaint?

In our simple example, we just call repaint inside the Animator callback. For the duration of the animation, the component will be repainted.

Sometimes you will have overlapping Animators that you’ve composed with AnimatorSetBuilder. To avoid calling repaint separately in each, you can create an Animator that always runs and calls repaint, like so:

const auto repaintAnimator = ValueAnimatorBuilder{}
    .withValueChangedCallback ([this] (auto) { repaint(); })
    .runningInfinitely()
    .build();

What I’m concerned about is the .runningInfinitely() with a callback calling repaint. Surely this doesn’t mean it’s going to be repainting continuously as that would be nuts - but then I don’t quite understand how it would avoid doing that.

The natural response would be “if you don’t want to keep repainting, don’t set it up.”. Sure, but then how do we then coordinate multiple active animators each calling repaint() on the same component?

Any thoughts or clarity would be greatly appreciated! :slight_smile:

Cheers,
Jeff

2

I’m wondering if coordination could be done by each animator setting an atomic bool animatorXNeedsRepaint to true if needed.

The paint() method could skip or paint and set to false.

Meanwhile the infinitely running repaintAnimator could be the only one that actually calls repaint().

Was that was the intention all along or am I thinking about this the wrong way?

3

Bear in mind that a call to repaint does not mean it will repaint immediately, synchronously. It merely marks the component as dirty and that it must be redrawn at the next opportunity.

4

Thanks, for the reply. Yes I had thought about that too - which made me wonder why:

To avoid calling repaint separately in each, you can create an Animator that always runs and calls repaint, like so:

was even a consideration worth avoiding.

5

Obviously, as with all things, one should measure if it has an impact, but in this case I doubt it is significant, assuming a repaint is needed anyway as the component is animating.

1 Like
6

If you have several short-lived animations that might overlap, it’s fine for each one to call repaint() individually. The repaint mechanism will never paint any faster than the screen refresh rate, so this shouldn’t result in any unnecessary work.

I think the technique being discussed is probably most useful when the app is continuously showing multiple animations, in which case moving all the repeated repaint calls to a single location might help to make the code a bit more concise.

1 Like