> it is genuinely hard to write an abstraction that provides adequate control of advanced GPU features (such as the compute capabilities) across subtly different low-level APIs.
> these traditional techniques can start to perform very badly in 2D once there are lots of blend groups or clip regions involved, since each needs its own temporary buffer and draw call.
One doesn’t necessarily need temporary buffers or draw calls for that, can also do in the shaders, merging into larger draw calls.
> What this comes down to is instructing the operating system to embed a video or 3D view in some region of our window, and this means interacting with the compositor.
That indeed works in practice, but I don’t believe the approach is good. Modern GUI frameworks are using 3D GPUs exclusively. They don’t need much efforts to integrate 3D-rendered content.
> [hardware-accelerated graphics abstraction is] a solved problem in C++
I think that would strike most people who work with computer graphics as a highly questionable statement. There's many, many different graphics abstractions out there for C and C++ alone, and none of them is The solution that is ideal for everything.
> > The rasterization techniques used in 3D are poorly suited to 2D tasks like […] antialiasing
> That’s subjective, I think these techniques are awesome fit for 2D. […] I have recently documented my antialiasing algorithm
Your comment actually reinforces the original author's point. You're using a completely different kind of anti-aliasing technique for 2D than would be used for 3D!
> Modern GUI frameworks are using 3D GPUs exclusively.
That doesn't make it easy. You don't control what the system UI framework is doing with the GPU.
> There's many, many different graphics abstractions out there for C and C++ alone, and none of them is The solution.
There’re downsides of course (that thing is C++ only because exceptions, requires recent enough hardware e.g. minimum GLES version is 3.0, and a few others), but in general that one is actually good. On the very high level, developers have re-implemented D3D12 over the rest of them.
Things like Angle and BGFX expose APIs which are very far from how GPU actually work, and close to the legacy stuff like D3D11 or OpenGL. For complex enough scenes, it’s pretty much impossible to get good performance on modern hardware with these APIs.
Game engines are designed in a way which does allow them to leverage the hardware, but they are huge, implementing many high-level things like assets pipelines, and are more like frameworks than libraries.
> Your comment actually reinforces the original author's point
Rendering an indexed triangle mesh with a vertex + pixel shader is the traditional rasterization technique. Compute shaders like piet-gpu, or custom vendor APIs like NV_path_rendering are examples of untraditional ones.
> You don't control what the system UI framework is doing with the GPU
Indeed, but good ones support explicit interop: WPF has D3DImage, UWP and WinUI have SwapChainPanel.
That’s a solved problem in C++, see this library: http://diligentgraphics.com/diligent-engine/
> The rasterization techniques used in 3D are poorly suited to 2D tasks like clipping to vector paths or antialiasing
That’s subjective, I think these techniques are awesome fit for 2D. See this library: https://github.com/Const-me/Vrmac#2d-graphics BTW I have recently documented my antialiasing algorithm: https://github.com/Const-me/Vrmac/blob/master/Vrmac/Draw/VAA...
> these traditional techniques can start to perform very badly in 2D once there are lots of blend groups or clip regions involved, since each needs its own temporary buffer and draw call.
One doesn’t necessarily need temporary buffers or draw calls for that, can also do in the shaders, merging into larger draw calls.
> What this comes down to is instructing the operating system to embed a video or 3D view in some region of our window, and this means interacting with the compositor.
That indeed works in practice, but I don’t believe the approach is good. Modern GUI frameworks are using 3D GPUs exclusively. They don’t need much efforts to integrate 3D-rendered content.
As for the video, one only needs a platform API to decode and deliver frames in GPU textures. Microsoft has such API in the OS: https://docs.microsoft.com/en-us/windows/win32/api/mfmediaen... Once upon a time wanted to do the same on embedded Linux, wasn’t easy but still doable on top of V4L2 kernel calls: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo