Hi @mhbj
Sorry, I meant to write line 229 (I’ve edited my reply above). As you mentioned, changing that line seems to solve the performance problem - at least for me for this test app that I wrote.
Unfortunately, JUCE 5.1 is a bit different with regards to that worker: users can add work to the gl thread while locking the message thread and blocking it - waiting for the job to finish.
My current idea is to remove any type of spinning altogether. I’ve implemented this on my private github account here. It works for my test app: performance is good, the locking code is no bottle neck anymore and there are no lock-ups on shutdown (or when processing jobs via OpenGLContext::executeOnGLThread), but it obviously still needs a lot of clean-up and a thorough code-review/testing as this is a really sensitive part of the JUCE codebase.
Let me know if something like this would work for you (it’s probably best for you to do a diff with the develop branch to better see the changes).