Yes, renderFrame will be called without the MM lock being acquired if needsUpdating is false. This will happen if you have continuousRepaint enabled and none of the components are dirty (i.e. need updating). You can easily see this if you run the JUCE demo and open the “OpenGL” teapot demo. After the components have settled, enable a breakpoint at juce_OpenGLContext.cpp:249: you will see that the message manager won’t be locked (mmLock=nullptr).
[quote=“pmr, post:1, topic:22503”]
If renderOpenGL() and the JUCE message loop both acquire the MM lock then why have them be on separate threads anyway?
[/quote]
It wouldn’t make sense to have them on separate threads if both would always acquire the MM lock. But as stated, this is not the case. Basically, the use-case that JUCE is solving, is having pure OpenGL animations along-side some (mostly) static JUCE components - like in the teapot demo. In these sort of use-cases the renderOpenGL render callback will run independently from the message thread.