Is repaint safe with message lock, on glThread?

General JUCE discussion
1

I am using opengl with juce and sometimes I need to trigger repaint again so I do this

void MainComponent::renderOpenGL()
{
  if (someCondition){
    juce::MessageManagerLock mmlock(juce::ThreadPoolJob::getCurrentThreadPoolJob());
    repaint();
  }
}

so far i never had any issues with this and everything works fine. Looking through the code I also cant see any issues, And the fact that paint/renderOpenGL also get called on the gl thread makes me believe that is it is safer than even the main thread.

I can always dispatch the repaint to the main thread but I want to get I better understanding of the engine.

I looked through other similar topics such as this one renderOpenGL() and repaint() function

but none of them take the message lock.

2

Instead of taking the MessageManagerLock it would be better to schedule the repaint on the message queue:

if (someCondition)
{
    juce::Component::SafePointer<Component> safe (this);
    juce::MessageManager::callAsync ([safe] { if (safe) safe->repaint(); });
}

But TBH I think if you need to trigger a repaint from the paint itself, it seems your architecture is flawed. The paint should not have any side effects, so a repaint() would result in the same.
Seems to me you do something in paint() that should happen independent from paint.

3

hey, I just want to go into continuous repaint mode for a little bit, in order to support user controlled animations similar to a game. Most of the time my app is not in this mode though. I just want the fastest repaint I can get, and doing what I did seemed to be the easiest approach. Scheduling on the main thread seems to be a convoluted way of doing the same thing. There is nothing in the JUCE docs that say it is unsafe to call repaint in paint(with message lock), and I dont get any asserts or issues with this. Also I dont want to use a timer cause it might miss repaints with a high time interval, and setting a low timer will just call a bunch of unnecessary repaints and make the computer do more work. The timer also requires me to add more state to my program.

Testing the time between my paints, I get slightly better times when I call repaint directly than if I schedule on the main thread. (though I only took a few sample tests)

Anyway Im not really concerned too much with architecture, just want to know if calling repaint in paint is safe with the message lock, and if not why? If its truly unsafe than it should be in the docs and throw an assert if possible, Thanks appreciate your response!

4

Haven’t written an OpenGL code inside JUCE, but my understanding was in continuous repaint mode, it renders into a framebuffer and once the paint() routine returns the buffer is swapped and it will immediately start to render again.

That means if I got that right, there is no need to call repaint at all, the buffer swap has basically the same effect like calling repaint(). On the contrary, the repaint() call might simply show the old frame again, but that is just a hypothesis.
If somebody has more insight please correct me.

repaint() is guarded with the JUCE_ASSERT_MESSAGE_THREAD macro, because it will access the same data like the OS routines, but I assume the framebuffer swap of OpenGL has it’s own synchronisation method.