Multiple instances of VBlankAttachment

1

Hello,
I have one juce::Component myMainComponent; on which I have multiple children of other juce::Components. I would like to sync with display refreshing all childred components, and myMainComponent can also be painted in sync but I actually I don’t care. So does it make any difference if I instantiate multiple VBlankAttachment (one per each child component) or when I make only one instance of VBlankAttachment for myMainComponent?

Are there any recomendations what solution is better? Or it is only dependent on what is more comfortable for me?

I tried to understand what is going on in the depth of VBlankAttachment but I am too weak in understanding such things so for any help or advice great thanks in advance.

Best Regards

2

It’s about your comfort, and whatever makes sense in the given situation.

There’s no reason why the child Components can’t all have their own attachments.

But I can imagine a situation where you just don’t need more than one. If the Components are guaranteed to be children of this one main Component, and all you want to do is call repaint() in the attachments, then calling it only in the parent may be enough.

But you may want to do more than just repaint(), so yeah, whatever’s best suited to your use-case.

1 Like
3

In addition to animation usages, I’ve started (happily) using VBlankAttachment as an alternative to timers in the UI (to trigger repainting of visualizers and other UI that update on parameter changes).

The approach I was using before was using timers to pick up atomics (set by the audio thread on param change), which seems to be the safest approach, as calling repaint from the audio thread is dubious, AsyncUpdater isn’t to be used on the audio thread, and the parameter changed callbacks (like in the apvts) are again not the best place to be doing things with components.

Now, when parameters change, I still set an atomic flag on the component. The component has a VBlank callback looking for that flag. When true, it calls repaint(), flagging the component as dirty. The nice part about this is it happens immediately inline with the next paint call (the timer approach sometimes had drawbacks and glitches since the timer fires at unrelated rates to paint calls).

Edit: I’ve also been assigning the VBlankAttachment to be empty/default constructed on visibilityChanged to save polling for the atomic when the components aren’t visible.

5 Likes