# VBlankAttachment and how does it work?

**URL:** <https://forum.juce.com/t/vblankattachment-and-how-does-it-work/62645>\
**Category:** General JUCE discussion\
**Created:** [August 28, 2024, 4:21pm UTC](https://forum.juce.com/t/vblankattachment-and-how-does-it-work/62645 "2024-08-28T16:21:14Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![jimc](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/jimc/32/16067_2.png) [@jimc](https://forum.juce.com/u/jimc)\
**Post date:** [August 28, 2024, 4:21pm UTC](https://forum.juce.com/t/vblankattachment-and-how-does-it-work/62645/1 "2024-08-28T16:21:14Z")

</div>

Can someone who knows a bit about this explain this one.

My knowledge is like this…

So your monitor has some refresh rate.

VBlankAttachment triggers a call on some callback at the refresh rate, and when? Immediately after the previous display refresh.

And then you call repaint().

This tells the OS you wanna repaint, so it calls back via ComponentPeer and your paint method gets called.

And this is guaranteed, or likely to happen before the next refresh happens?

It’s all a bit of a mystery 🙂

---

<div class="post-metadata">

**Author:** ![LightandSoundLTD](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/lightandsoundltd/32/11898_2.png) [@LightandSoundLTD](https://forum.juce.com/u/LightandSoundLTD)\
**Post date:** [August 28, 2024, 4:40pm UTC](https://forum.juce.com/t/vblankattachment-and-how-does-it-work/62645/2 "2024-08-28T16:40:23Z")

</div>

I think of it as as way to prepare data between paint calls. You can repaint using a timer and just do changes to the data in vblank callback, or just use the vblank callback to do the repaint call.

This also means you can use it to avoid paint calls if the data hasnt changed, so its like a nice way to check if its worth doing each callback.

---

<div class="post-metadata">

**Author:** ![sudara](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/sudara/32/8071_2.png) [@sudara](https://forum.juce.com/u/sudara)\
**Post date:** [August 29, 2024, 11:52am UTC](https://forum.juce.com/t/vblankattachment-and-how-does-it-work/62645/3 "2024-08-29T11:52:43Z")

</div>

> [@jimc](#):
>
> and when? Immediately after the previous display refresh.

Good question, I always think of this as as “a hook right before the next paint() call propagates down from the peer to your components.” So maybe “immediately before the next refresh” or “on next refresh” is more accurate (depending on the implementation).

Reading code again, vblank callbacks fire right right before the OS is notified about what’s dirty, it’s clearest on windows:

```cpp
    void onVBlank() override
    {
        vBlankListeners.call ([] (auto& l) { l.onVBlank(); }); // your callbacks, if any
        dispatchDeferredRepaints(); // tell the os to invalidate rects

        if (renderContext != nullptr)
            renderContext->onVBlank(); // D2D calls peer.handlePaint()
    }

```

So basically, it’s a “last chance” for a component to mark itself as dirty (via `repaint`) right before the cascade of paint calls happen.

Inside the vblank callback, I often just test if a boolean has changed (for example a parameter changed which means a visualization needs to change, or animation is running) and then call `repaint()`. I do treat it as guaranteed to be repainted on the next OS paint, but I haven’t “proven” this empirically.

I’m less clear on the exact mechanism on macOS, but it seems to be an AsyncUpdater calling the `onVBlank`, and that’s all wired up to a `CVDisplayLink` which is an OS notification that a paint is about to happen. This part seems like magic to me!