# Callback on repaint? **URL:** \ **Category:** General JUCE discussion\ **Created:** [November 17, 2017, 11:35am UTC](https://forum.juce.com/t/callback-on-repaint/25165 "2017-11-17T11:35:09Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![adamwilson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/adamwilson/32/1387_2.png) [@adamwilson](https://forum.juce.com/u/adamwilson)\ **Post date:** [November 17, 2017, 11:35am UTC](https://forum.juce.com/t/callback-on-repaint/25165/1 "2017-11-17T11:35:09Z")
I’m in a situation where I need to know when a component has repainted itself. I can use the (very handy) `Timer::callAfterDelay` method to delay things, which works most of the time, but obviously the delay required varies across devices. Also feels too much like a hack. Would be nice to have an optional callback parameter to e.g. ```cpp repaint (std::function callback = nullptr) ``` so we know when a repaint has completed. Unless there is another way around this problem? **EDIT** - rereading the documentation, I see this may not be possible as it’s waiting for the OS to do the redrawing… ---
**Author:** ![dave96](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/dave96/32/8487_2.png) [@dave96](https://forum.juce.com/u/dave96)\ **Post date:** [November 17, 2017, 1:40pm UTC](https://forum.juce.com/t/callback-on-repaint/25165/2 "2017-11-17T13:40:54Z")
Why do you need to know once it’s been repainted? The paint method should just draw the current state of the data, maybe there’s another event you should be hooking in to? (Also be careful with `Timer::callAfterDelay`, if you call this from your paint method, you’ll likely get a lot of callbacks, especially if your component is continuously being repainted, moved or animated in some other way). ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [November 17, 2017, 2:07pm UTC](https://forum.juce.com/t/callback-on-repaint/25165/3 "2017-11-17T14:07:24Z")
Also note, that it is bad practise to add side effects to painting, a) because they happen indeterministic (as a result of occlusions on the screen, resize or move actions and so on b) they might slow down painting c) bugs are hard to find there Only paint in paint! Good luck ---
**Author:** ![adamwilson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/adamwilson/32/1387_2.png) [@adamwilson](https://forum.juce.com/u/adamwilson)\ **Post date:** [November 17, 2017, 2:08pm UTC](https://forum.juce.com/t/callback-on-repaint/25165/4 "2017-11-17T14:08:19Z")
I’m not calling `callAfterDelay` from within the paint method - I’m using it to refresh a component which relies on some processing. I’ve nailed it down with lambda callbacks so I know when the processing has completed, but even with that it still occasionally fails to redraw unless I introduce a delay. ---
**Author:** ![dave96](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/dave96/32/8487_2.png) [@dave96](https://forum.juce.com/u/dave96)\ **Post date:** [November 17, 2017, 2:10pm UTC](https://forum.juce.com/t/callback-on-repaint/25165/5 "2017-11-17T14:10:52Z")
Is the processing on a background thread? Is it possible that the thread hasn’t actually finished and committed the results before the painting happens? Is it the `paint` method that’s not getting called or is the data you’re painting not ‘complete’ when the paint method is called? ---
**Author:** ![adamwilson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/adamwilson/32/1387_2.png) [@adamwilson](https://forum.juce.com/u/adamwilson)\ **Post date:** [November 17, 2017, 2:22pm UTC](https://forum.juce.com/t/callback-on-repaint/25165/6 "2017-11-17T14:22:54Z")
Yes, its processing on a background thread. Pretty sure the paint method is getting called but the data is not yet complete. The thread calls `triggerAsyncUpdate` on completion (which should then trigger the repaint). Strange as there’s nothing on the thread that looks asynchronous. ---
**Author:** ![daniel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/daniel/32/790_2.png) [@daniel](https://forum.juce.com/u/daniel)\ **Post date:** [November 17, 2017, 2:46pm UTC](https://forum.juce.com/t/callback-on-repaint/25165/7 "2017-11-17T14:46:10Z")
Are you aware of the flow of repaint() and paint()? The repaint only marks an area as dirty. In the juce\_Component.cpp you see, that only the heavyWeightPeer calls the paint() callback. Otherwise it will stop at the component with no parent, see here: > The entry for the actual paint() is ComponentPeer::handlePaint() (easily found with a breakpoint) > So I think you don’t get a paint call without an addToDesktop() ---
**Author:** ![adamwilson](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/adamwilson/32/1387_2.png) [@adamwilson](https://forum.juce.com/u/adamwilson)\ **Post date:** [November 17, 2017, 8:28pm UTC](https://forum.juce.com/t/callback-on-repaint/25165/8 "2017-11-17T20:28:11Z")
That looks like a good clue. The component in question is embedded in an iOS UIView, and so Juce may think its not visible and therefore not schedule it for repainting. Some more investigation needed…