# Multiple instances of VBlankAttachment
**URL:** https://forum.juce.com/t/multiple-instances-of-vblankattachment/57242
**Category:** General JUCE discussion
**Created:** [July 31, 2023, 4:02pm UTC](https://forum.juce.com/t/multiple-instances-of-vblankattachment/57242 "2023-07-31T16:02:19Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@pajczur](https://forum.juce.com/u/pajczur)
#### Post date: [July 31, 2023, 4:02pm UTC](https://forum.juce.com/t/multiple-instances-of-vblankattachment/57242/1 "2023-07-31T16:02:19Z")
Hello,
I have one `juce::Component myMainComponent;` on which I have multiple children of other `juce::Component`s. 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
---
### Author:  [@attila](https://forum.juce.com/u/attila)
#### Post date: [July 31, 2023, 10:33pm UTC](https://forum.juce.com/t/multiple-instances-of-vblankattachment/57242/2 "2023-07-31T22:33:03Z")
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.
---
### Author:  [@sudara](https://forum.juce.com/u/sudara)
#### Post date: [August 1, 2023, 12:16pm UTC](https://forum.juce.com/t/multiple-instances-of-vblankattachment/57242/3 "2023-08-01T12:16:44Z")
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](https://forum.juce.com/t/repaint-threadsave/46319), [AsyncUpdater isn’t to be used on the audio thread](https://forum.juce.com/t/should-i-use-sliderlistener-for-component-updates-and-valuetree-listener-for-audio-thread-updates/34806/14), and the parameter changed callbacks (like in the apvts) are [again not the best place to be doing things with components](https://forum.juce.com/t/sending-signal-events-from-audio-to-gui-thread/27792/5).
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.