Update: after making a minimal reproducible example, it’s become clear that this seems to be an issue with JUCE + D2D that differs from the software renderer. You can see my example code in this repository. I’ve tried a couple of permutations, and the main offender seems to be using a lot of ColourGradients.
Obviously, this example is a massive overuse of JUCE’s graphics. Rendering dozens of random gradients every frame is clearly a huge no-no. However, the part that still concerns me is the fact that only on D2D, the entire DAW will freeze up along with the program window well before the framerate dips that hard on the plugin UI itself.
(Obviously this is a call on our side to refactor aggressively, as this problem doesn’t occur unless the paint routines are way heavier than they should be. However, I’ve also bumped into an issue regarding effective optimization of ColourGradient, which I’ve outlined here)
If this is simply a symptom of worse performance, and it’s normal that a clogged render queue will block the message thread, then I’d consider my current issue resolved and pivot to viewing this as an optimization problem. Just wanted to make sure that this was on the JUCE team’s radar in case the mouse interaction lag isn’t expected.
P.S. I’ve tried your D2D debug tip, but nothing seems to come out in the logs.