Mutiple OpenGLContext issue


I have a app supporting dual monitor.
Both have background image updating regulary, so I used opengl like OpenGL 2D Juce Demo.
I have 2 OpenGLContext, one is for main window and other for second monitor.
But it uses very higher CPU(2x) than not using opengl and app does not respond but updating is normal.
Profiler shows below.

juce::MessageManagerLock::MessageManagerLock 24.52 %

What is right way to support dual monitor with opengl?

OS: Windows 10 x64


On what system are you testing? macOS?


System: Windows 10 x64


Juce is known to not handle multiple OpenGL contexts well when using the Juce Graphics to draw. The same issue appears when using OpenGL in audio plugins with multiple instances open at the same time.
At least for me that makes using OpenGL a no-go for plugins although I really would like to use it.

Rendering multiple instances of a plugin with OpenGL.


It’s on our radar - Fabian was working on a solution because we need it for NOISE, I think.


Sorry for being so offtopic, but If would be cool if also the 2d-openGL renderer will gets an update to work more efficient.

Also i have a very cool feature in mind, which could massive improve graphics efficiency.
An optional component-flag, which tells juce, that its allowed to call the paint(Graphics&) call-back from a non-message-thread.

This way the juce graphics renderer could call them from a (multiple) background threads, and compose them afterwards. (Or maybe advanced, use the OS to compose the layers, like what happens to simple windows)


Yeah, I’ve got a few ideas I’d like to have time to investigate as far as optimising the drawing goes.


Another idea just comes to me mind, if all paint methods during a paint-call would be serialized and pipelined into a ring-buffer, and than processed by a background thread (of cause this is an issue with references to images).
So existing code can rely on the message thread, and we have still a massive speed improvement.


Yes, that’s also an idea I’ve thought about. The tricky bit is where assets like images are involved, because they could be changed after drawing them, and all kinds of race conditions would need to be handled.