I’m seeing a hard to reproduce repaint issue when I’m using the JUCE_COREGRAPHICS_DRAW_ASYNC=1 flag on a JUCE window with a native title bar (these two things seem to be required for the repaint bug to happen).

It happens more often when using 2 screens and multiple ‘Spaces’ , but I also get it (rarely) on my macbook with no external screen attached.

The bug happens mostly when switching between two spaces. Sometimes, the juce window appears black, or partially black: it is not repainted when being unhidden and all parts which are not actively repainted ( like with a repaint() call in a timer callback) just stay black. It happens with juce 6 and also juce 5.

Of course, I can disable JUCE_COREGRAPHICS_DRAW_ASYNC , but this flag makes such a difference in repaint speed that I would really want to keep it.

I wonder if I’m the only one here to notice that issue (my colleagues can also reproduce it with a toy juce application). The issue is very rare on my laptop, but some customers seem to trigger it quite often (many times per day).

1 Like

It happens to me occasionally but I’ve not had a chance to dig in to why.
Mousing over components seem to bring them back and I think minimising the window and restoring it can help (or maybe resizing it) so I’ve just been doing that.

Maybe a full repaint is needed when the window regains focus?

Yes the black area disappear as soon as your code calls repaint() for the component, however minimising/restoring or switching spaces does not trigger repaint, so black areas can stay for a very long time. Maybe calling a repaint() on the top level component every 10s will fix that, I’ll try it.

I have a customer reporting this as well when using virtual desktop.(spaces)