The issue seems to be that having multiple instances of these plugins in the DAW means the concurrent OpenGL calls create an interleaved set of commands - causing the GPU to have to switch contexts constantly to carry out what we need. This type of situation is described here in this post under the “Performance” section:
https://blog.gvnott.com/some-usefull-facts-about-multipul-opengl-contexts/
When I run the plugins as standalone applications (or in a host that supports running plugins as dedicated processes), the issue does not occur, but not many hosts currently support dedicated-process plugins.
I had noticed there is the NativeContext::Locker object, but the body of that class only seems to apply to macOS and not Windows or Linux. It seems that would need some sort of synchronization code implemented for these platforms?
Likewise, using setComponentPaintingEnabled(true) should keep these calls in the correct order - since only one context can be holding the MessageManager lock - but with it enabled we still run into the issues described here:
Our Win10 test machine uses an AMD Radeon RX 480 with driver version 22.19.172.769 for reference