Once you’ve installed the debug layer, go to juce_DirectX_windows.h in modules/juce_graphics/native. Look for the initializer for the Direct2D factory (around line 258):
D2D DEBUG INFO - PERF - A layer is being used with a NULL opacity mask, 1.0 opacity, and an axis aligned rectangular geometric mask. The Push/Pop Clip API should achieve the same results with higher performance.
I get these with all three renders.
I don’t see any other errors beside the “Microsoft C++ exception: IntegerOverflowException” ones, that are few and far between compared to the D2D DEBUG INFO ones.
The IntegerOverflow exception does trigger with some fonts, for example Figtree:
auto font = juce::Font(juce::Typeface::createSystemTypefaceFor(BinaryData::FigtreeRegular_ttf, BinaryData::FigtreeRegular_ttfSize));
g.setFont(font);
g.drawText("test", getLocalBounds(), juce::Justification::centred);
Now I am seeing a very strange behavior that only happens with the JUCE 8 Direct2D renderer (JUCE 8 software and openGL renderers are OK, as well as the Direct2D JUCE 7 one).
In short, past a given window size (eg 2500px wide), when dragging a slider on one side of the interface with an animated path occurring on the order side, the dragging gets really choppy. Dragging other sliders closer to the side with the animation does not trigger that choppy behavior. The further apart the choppier it gets.
I see no error or warning in Debug mode.
This will be difficult to reproduce/isolate, so does that ring a bell right off the bat?..
Here is an example demonstrating the behavior.
On my system (14900k iGPU, 4k 60Hz monitor) with the window maximized, looking at the GPU usage in task manager I go from around 35% when both animations are on the same side to around 45% when they are on opposite sides.
I can confirm that I see higher GPU usage in Task Manager with your example with the animations on opposite sides.
However, in my case (with JUCE 8) the GPU usage is around 0.8% with both animations to one side, and 1.4% with the animations on opposite sides. I’m using an Nvidia 2080Ti, so there’s clearly a difference between the GPUs.
I see similar results with JUCE 7.
I’ll see if I can dig up a machine with an integrated Intel GPU.
You might learn more if you open Task Manager, go to the Performance page, and select your GPU. You’ll see more detail about your GPU resources. Looks like your particular GPU doesn’t have dedicated VRAM, so that may cause performance bottlenecks.
Running the same code on a Ryzen 4800U laptop (iGPU again) on a 4k display results in a GPU usage of around 17% (same side) and 22% (opposite).
I cannot expect my users to have a better GPU than that on average.
In fact most non-gaming Windows laptops will have this kind of configuration.
I see the same behavior with the JUCE 7 Direct2D branch indeed, but the plugin I am working on was running smoothly with the JUCE 7 Direct2D branch on all my test machines (including one with an Intel m5-6Y54, which is a 9 years old CPU that barely manages 2GHz), and now it struggles with all of them in JUCE 8 (none of them have dedicated GPUs though).
I tried removing the shadows and using default fonts to silence the warnings mentioned in this thread, but that does not seem to solve the speed issue.
It also affects the software renderer.
By the way, in the above example repainting the whole window at the same rate as the animations does seem to get the GPU usage down.
I’ve coincidentally also used the Figtree font, which explains the Integer overflow exceptions, but I’m confused about why. First, I use only ASCII characters (no Unicode in sight); second, shouldn’t the fallback mechanism handle all missing characters?
Performance: I have the opposite experience of @fuo. With ultraSID, the D2D branch of JUCE7 is very stuttery and laggy and seems to struggle a great deal (bad frame-timing). With the JUCE8 branch, everything is butter smooth. This is with a GTX 1060 6GB, an eight-year-old GPU.
From my experience, we can expect users to have much better GPUs than the iGPUs @fuo mentioned. Whenever we get a support file (so from non-power users who need help with simple stuff), they have something like a 2080 or better.
It’s all certainly much faster than with the software renderer, especially at higher resolutions.
I just found something strange by accident: it looks like setting opaque to true does increase GPU usage.
Removing all setOpaque calls in different components of the plugin I am working on, GPU usage is now similar to that of JUCE 7 D2D (software renderer is still much slower though).
This can be verified with the example code I posted above. calling setOpaque(true) for TestAnimation, and of course calling fillAll in paint(), does increase GPU usage by a substantial factor:
Edit: strangely enough, I see the same phenomenon in JUCE 7 D2D, and GPU usage is even greater than JUCE 8 in the above example, but for some reason this is a different story in my plugin. Tracking down the exact thing that makes JUCE 8 slower in my app might be difficult. In any case, dropping setOpaque does close the gap for me, at least for the d2d renderer.
