I have had similar issues in Cubase on Windows.
Every component repainting (especially moving) on the OpenGL-thread requires there MML-lock. (And something like painting complex shapes, will also involve the CPU, because JUCE renders the shape into edge-tables first on the CPU)
I guess because there is only a limited time on the message-thread - which is also shared with the host - this can cause unresponsive behaviour. (And too much OpenGL time, also)
Besides things what the JUCE-Team can do, (reserve some time for the message thread, or other optimisations) you can try to offload your animations to pure low level OpenGL inside the renderOpenGL() callback.
Because this doesn’t involve the message-thread.
I also use the OpenGL Context inside the GL-Callback, so I can comfortably draw 2D Graphics via the juce::Graphics class (At least if you don’t use any text-rendering which requires the message thread)
An earlier JUCE-Demo did the same, I wonder if its officially supported for this application)
something like this
void MyComponent::renderOpenGL() override
{
std::unique_ptr<LowLevelGraphicsContext> glContext (createOpenGLGraphicsContext (*glContext,width, height);
Graphics g (* glContext);
g.drawEllipse (0.f, 0.f, 20.f,20.f, 1.f);
g.drawSomethingWithoutInvolvingMessageThreadEtc()
...
Another thing you can do, If a component a only moves, but doesn’t needs to be redrawn, set setBufferedToImage(true), which maybe helps.
And of cause using a profiler helps, to find performance spots on the repainting routines.
I’m curious what the others say.
Of course, your problem could be due to something else entirely.
PS:
If wish there would be something like setContinuesRepaint on Component-Basis. Which let the OpenGL Renderer calling the paint()-methods without locking the Message-Thread directly. (Of cause paint needs to be thread safe designed then)
Edit: renamed Renderer to Context, to make it clear