Does Direct2D cache the painting function?

Direct2D
1

My equalizer plugin allow users to choose UI colours. When they press the save button of the UI settings, the main editor will call sendLookAndFeelChanged and paint everything with the new colour(s). The plugin won’t save a copy of the old colour(s).

One user (Windows 11 & Cakewalk Sonar) reported a very strange bug(?). When he save the new colour, the plugin paints itself with the new colour. However, when the plugin window is moving, the plugin paints itself with the old colour. And when the plugin windows stops moving, the plugin paints itself with the new colour again.

From the following video:

  • at 0:50, the background colour is gray
  • at 0:57, the background colour is saved as blue
  • at 1:00, you can see the whole spectrum is blue
  • at 1:02, the plugin window is moving and the spectrum turns gray
  • at 1:04, the plugin window stops moving and the spectrum turns blue
  • this issue still exists until the user close & reopen the plugin windows at 2:22

Is this a bug? Or it is because Direct2D caches the painting function/colours somewhere?

2

Interesting…it does have a “cached” smell. Are you on latest develop? Are you using setBufferedToImage somewhere? [Bug] Issue with setBufferedToImage and Direct2D Rendering in JUCE 8 - #6 by psyDSP

3

It is on JUCE 8.0.1 (not the latest develop). All setBufferedToImage has been removed because of its poor performance on the spectrum.

4

The renderer reuses a D2D solid color brush and just sets the color as needed.

Is the problem reproducible with your plugin in standalone mode?

Is your plugin editor set to be opaque?

Matt

5

The issue I described occurred on a user machine. On my local machine it is different. The UI with the old colour only appears once (several frames?) when I close the plugin window. It seems that the standalone does not have the issue.

The backgrounds of the spectrum and the UI setting panel are set to be opaque. However, the sliders on the bottom (and their background) are not opaque. But they are also affected.

The following plugin with a much simpler UI also has the same issue GitHub - ZL-Audio/ZLSplitter: splitter plugin .

6

Have you noticed that, between 0:14 and 0:18 more or less, there is the part of a window frame with a title painted inside the plug-in bounds?

It’s interesting to notice that after 0:18 it briefly disappear, only to appear again at 0:21 the exact moment that the plug-in window is dragged around.

I assume that the spurious “native window frame” that appears is not painted by the plug-in at all, and is a visual artifact of some kind. It looks to me like there is some “optimization” setting somewhere (might be at OS level or in the DAW) that, when moving windows around, takes a screenshot of the content and displays that during the move rather than continuously repainting. And that screenshot being moved, sometimes it’s not taken at the right time.

One test you could do is to put something animated in your plug-in (for example, a label continuously updated with the current time on a Timer), and see if the animation continues during the drag operation or if it freezes.

7

Is it definitely using 8.0.1, including this patch? JUCE 8.0.0 had an issue where regions of previously-drawn frames could sometimes end up getting displayed, but that should be resolved in 8.0.1. It would also be interesting to know whether you can reproduce the issue on the very latest develop.

8

I agree. I will set up a simple plugin with a timer and see what happens.

It is on 8.0.1 (as you can see from the github repo). I will set up a simple plugin with latest develop. BTW this issue seems to be hardware related.

9

The test repo is here, a clock which changes its colour when you click.

Thanks @yfede suggestion. My original assumption is wrong. When I change the colour and close the plugin, I see an old time string. At least on my local machine, the whole painted frame gets cached, not the colours. Perhaps OS will do some optimization if repainting when moving is a heavy task.