The docs on “repaint” say that “Calling this will not do any repainting immediately, but will mark the component as ‘dirty’”. So this might mean that repaint is thread save.
Hence I tried to call it fom the the audio block callback in a plugin. Here I got a rather funny result. If I compile my code to a VST2, it works fine, if I compile it to a VST3 it crashes immediately hen loaded.
Of course when using a time to poll for the change in the display that needs to be shown, it works on VST2 and on VST3. (I know I could use an event as well,m but this is just a testing project…)
-Michael
Component::repaint() is NOT thread-safe, and AFAIK neither are any of the other Component methods.
Are you not hitting the assertion inside Component::internalRepaintUnchecked()?
You can use a MessageManagerLock if you really need to call a Component method from some thread besides the message thread, but as you mentioned, a timer or event-based approach probably makes more sense for something simple like triggering a repaint.
In fact I wanted to express my astonishment that it works as a VST2 and crashes as a VST3. I did not run it in the debugger, so I did not see the assertation.
Good to know !
In a non-testing project in such cases I would use triggerAsyncUpdate.
In fact it would be nice if “Component” would additionally feature a thread save repaint variant.
Thanks again,
-Michael
There are reservations against triggerAsyncUpdate() from the audio thread as well, because it posts a message to the message thread.
One scenario was a lock around the message queue (OSX) and another was if many messages are posted in a short time, it might allocate (Windows) IIRC.
Have a look at @dave96 s talk at the audio programmer meetup:
Seems like a bug, as triggerAsyncUpdate() seems like being provided for exactly that purpose ?!?!?
-Michael