> I don't know why you're confidently saying something incorrect, it took me all of 2 minutes to find the source code and read it. I'd say we just have differe

> I don't know why you're confidently saying something incorrect, it took me all of 2 minutes to find the source code and read it. I'd say we just have different definitions of GPU-accelerated. Your position appears to be "purist" in the sense that almost all processing needs to happen on the GPU. But for me, if mostly static data is generated on the CPU once and then cached on the GPU and then processed on the GPU in all performance-critical contexts, then I would call that "GPU-accelerated" even if parts of the data preparation happened on CPU. That's also why I brought up the UE. They prepare the data on the CPU, then send it over to the GPU so that rendering in the real-time loop can happen only on the GPU. But the fact that the CPU prepared the data does not make it not-"GPU-accelerated" for me. That said, can we agree that the ID2D1GeometrySink that JUCE uses on Windows is GPU-accelerated? Surely the Direct2D/DirectX drivers will do stuff on the CPU, but Microsoft says "Direct2D is a hardware-accelerated, immediate-mode 2-D graphics API" and they show very smoothly antialiased splines here while mentioning "Multisample Antialiasing", a GPU feature: https://learn.microsoft.com/en-us/windows/win32/direct2d/direct2d-overview https://learn.microsoft.com/en-us/windows/win32/direct2d/dir...