We pinned down a problem we have on Windows, particularly in Ableton Live (11 or 12), where the entire Application UI freezes/becomes unresponsive, when our plugin UI is open (repainting in a timer, multiple instances make it happen quickly, but it has also happened with just one instance) and the Ableton Spectrum device is open/visible and maximized (but I believe, something similar could happen without Spectrum as well).
The cause seems to be, that JUCE doesn’t use the WM_PAINT message to repaint when using OpenGL or D2D, as the system (or Ableton, not sure) mediates WM_PAINT messages based on some rules, such that the App can stay responsive. Using the software renderer, we can open as many instances in parallel to the Ableton Spectrum without freezing the App (only the most foreground windows keep repaint though, but thats kind of OK, given how few milliseconds are available to paint between frames).
We experimentally modified JUCE to repaint with D2D through WM_PAINT, and that really fixed the issue, while it presented some other problems we didn’t want to go into.
Wouldn’t it be possible for JUCE, to offer the option to not use the VSync-Thread to repaint D2D windows, but to handle painting the usual way, through WM_PAINT?
We used 8.0.3 to test D2D, and have had the issue with OpenGL in JUCE 7.x for quite a while. Deploying different JUCE versions does take some work for us, so we didn’t try the develop branch yet. Can the latest/develop version paint with D2D through WM_PAINT? Or does it have any other mitigation for repaint overload? If so, we’d try that version.
There was a change to the vblank mechanism intended to avoid saturating the message thread with paint callbacks. This sounds like it might be related to the issue you’re seeing. The change was added in 8.0.5.
But I still think, it would be better to trigger repaints through WM_PAINT on Windows per default, or at least as an option. Easiest and most reliable. Don’t know about timing issues with VBlank, but I’d definitly prioritze that below. Otherwise, having a complex solution to fix multi-instance repaint-overload, I’d never be too sure if it wouldn’t break in some host/situation.
