I’m still not 100% certain why it happens. Unfortunately it’s a highly async process and absolutely non-trivial to grasp with conventional debugging. GL commands do not block until the work is done! Internally , on the driver side, they can (and ideally should) be executed much later.
Now, even if the plugin instances use multiple different OpenGLContexts, the underlying GPU / Driver must somehow queue the command buffers in order. Since the plugin instances run in parallel, the GL driver regulary switches between a “current” context (due to wglMakeCurrent). A context switch implicitly flushes the command pipeline, triggering command execution all over the place. Unfortunately some flushes can trigger intensive rendering, which stalls the CPU until it’s synced with the GPU. This results in other plugin instances becoming unresponsive.
There are multiple things that cause flushing of the pipeline. Reducing this can improve the issue and even solve it completely. I discovered multiple causes, explained in detail this thread:
Although I have to say, I haven’t tested these fixes with the newest changes. But this issue definitely existed before them!
Anyway, the non obvious thing here is that a simple glError query in one plugin instance can trigger stalling in another instance. An implicit CPU<->GPU sync. So reducing the amount of syncing in one plugin will improve the overall performance of all instances.