I guess we could add a withTransform() that returns a new path with the given transform, other alternatives that come to mind but Ive not given much thought to.
Path (I suspect there are some potential performance penalties to consider)Good point, I figured this is the best in-place path (no copying, etc). I was too lazy to to do that, figured itās not the end of the world to clear() and recreate when itās one rounded rect.
An in-place version of path.withOrigin (point) could be sweetā¦ I had a similar need in melatonin blur. To test whether or not a path changed (and therefore blur cache was broken), I store an āorigin agnosticā copy of a path. This allows for quality comparison and translation without blur recalculation (the translation offset later applied when compositing).
Edit: Oh wait, void Graphics::fillPath (const Path& path, const AffineTransform& transform) applies a one time transform while drawing! (via a copy)
What will happen on Win7, and Win8 when using JUCE8? Will it fall back to the Software renderer, or will JUCE8 drop support for Win7 and Win8 altogether? I remember reading that D2D requires at least Win10 because of one thing or another.
Forgot about that one, good find.
Minimum deployment targets in JUCE 8 are as follows (you can find these in the readme)
There were several reasons for moving to Windows 10, D2D was definitely a factor. We were already considering dropping Windows 7 support (I canāt remember the details there were some limiting factors for us), and adoption of Windows 8/8.1 seems poor. Some of the other considerations we included in taking this decision includeā¦
Hi @fuo - could you please be more specific about when you see the increased GPU usage?
Iāll try comparing the two branches.
Matt
Hi @matt,
When repainting components or changing their scale (dragging components around, changing complex knobs with a lot of paths and gradients, window resize with affineTransform scale, etc.).
This prompted me to check which versions of Windows our plugin is activated on:
1.2% on 8.1
2.3% on 7
The rest on Windows 10. Interestingly no reports of Windows 11 machines.
Are you on the latest of JUCE 7?
There was a bug where Windows 11 was still reporting as Windows 10 that was fixed a few months ago, IIRC.
No actually still on JUCE 6 for that oneā¦
We have about a 50/50 split between Windows 10 and Windows 11. ~3% on Windows 7 and <1% on Windows 8
I would be interested to learn not just how many are on Windows 7 but when those users installed or what version of your software they are running. i.e are they both running Windows 7 and expecting and installing the latest updates to your software? With Windows 7 now being 5+ years out of support from Microsoft I think itās time to move on. Itās always possible users can continue to make things work on Windows 7 if they choose but officially we would like to drop support and the value in supporting Windows 8 seems very low.
Actually those stats werenāt up to dateā¦ since we released the plugins in December, 0.3% of users have been on 7, 0.3% on 8, and the rest is a 50/50 split between 10 and 11.
@ImJimmi Thanks for sharing these stats!
nothing related to AI? 
Iām evaluating JUCE8 at the moment and am looking at animation on macOS. In the DemoRunner, the AnimationEasingDemo uses some of the new stuff. I see some minor judder even in a release build (especially noticeable on linear easing with a slow time). Itās not very bad, but itās definitely not as perfect as it could be and happens regardless of the renderer selected. This is on a mpb m1 pro with a 120Hz Pro Motion display.
Looking at the code, I see that the animation runs on a CVDisplayLink callback, and uses the time reported by Time::getMillisecondCounterHiRes() inside the AnimatorUpdater. This uses mach_absolute_time() internally.
Isnāt this the wrong time to use? From past iOS and macOS game development I remember thereās a timestamp in the CVDisplayLink callback that tells you the time when the frame will be displayed which should be much more consistent in relation to the display than mach_absolute_time(). I guess the current implementation also means that if various things are hooked up to the CVDisplayLink they might not all use the same timeStamp.
Or am I missing something? Is it possible to get the exact timestamp the frame is going to be displayed somehow in JUCE8?
Iāve pulled some numbers from our activations:
Win11 = 17%
Win10 = 80%
Win8 = 0.3%
Win7 = 0.3%
We have no valid information for the remaining 2.4%. I donāt believe anybody managed to run NEXUS or Vanguard in Vista.
Yeah, I think we can safely abandon Win7 and Win8.
Please could you provide a bit more information about exactly how the problem is triggered? Hereās what Iāve tried. Iām running Windows 11 @ 200% scale, juce8 branch.
#include <juce_opengl/juce_opengl.h> to the top of the header, and add the module to target_link_libraries in the GuiApp CMakeLists.txt.juce::OpenGLContext ctx; as a data member of MainComponent, and call ctx.attachTo (*this) in the constructor.I donāt hit any assertions when following this procedure. Are you definitely hitting JUCE assertions as opposed to the IntegerOverflowException errors you mention later on?
Iām also not seeing these overflow errors - do you have some additional diagnostic/debug options enabled in your IDE? I canāt trigger anything like this, even with Visual Studioās debugger set to break on all C++ and Common Language Runtime exceptions.
It would be helpful to see some example code for this problem.
The following example renders how I would expect:
class MainComponent : public juce::Component
{
public:
MainComponent()
{
setSize (600, 200);
}
void paint (juce::Graphics& g) override
{
g.fillAll (juce::Colours::grey);
juce::Image img (juce::Image::RGB, 100, 100, true, juce::NativeImageType{});
g.drawImageAt (img, 0, 0);
img.clear ({ 50, 50 }, juce::Colours::cyan);
img.clear ({ 0, 50, 50, 50 }, juce::Colours::magenta);
img.clear ({ 50, 0, 50, 50 }, juce::Colours::yellow);
img.clear ({ 50, 50, 50, 50 }, juce::Colours::black);
g.drawImageAt (img, 100, 0);
img.clear ({ 100, 100 }, juce::Colours::white);
g.drawImageAt (img, 200, 0);
img.clear ({ 100, 100 });
g.drawImageAt (img, 300, 0);
{
juce::Graphics x { img };
x.fillAll (juce::Colours::cyan);
}
g.drawImageAt (img, 400, 0);
}
};
It renders the same if I attach an OpenGLContext to MainComponent, too.
Iāll take a look at the performance issues you raised shortly.
Do you use an Nvidia card with up-to-date drivers, perchance? I see the same Microsoft exceptions during normal draw calls made with D2D, so it might be some driver issue that does not affect the result but may cause performance degradation due to the exceptions and their logging. 
I am using an Intel iGPU (14900k CPU) with up-to-date (albeit 2 years old) drivers.
Good to know. So, it doesnāt seem to be driver-dependent. Hope the @reuk finds a way to reproduce this. It floods the Debug output window and makes it useless for logging 
