Yes, exactly this -- it's a fast and convenient way for my code to just write the pixels into a spot in RAM (the CPU's RAM, not VRAM) and have those pixels end up on screen. On modern architectures this nearly always goes through a GPU, so even if you're not using the GPU to accelerate your 3D rendering/math, you gotta deal with it just to put pixels on a screen at the end of the day. So that's what wgpu does for me.
Most desktop OS compositors provide a void** buffer that can be blitted to. Sure, this buffer will probably end up going through the compositor which does GPU hardware acceleration anyway, but it is definitely possible to shrink the application-side stack without relying on D2D/GLUT/GLEW/GLFW/SDL/WGPU in this case.
In this case wgpu is just providing the surface texture for the window that the software rendered pixels are drawn into.
Softbuffer?
(I originally wrote this a few years ago but other people maintain it now)
I like softbuffer, but it owns its window and doesn't support as many events / integrations as winit.
Yes, exactly this -- it's a fast and convenient way for my code to just write the pixels into a spot in RAM (the CPU's RAM, not VRAM) and have those pixels end up on screen. On modern architectures this nearly always goes through a GPU, so even if you're not using the GPU to accelerate your 3D rendering/math, you gotta deal with it just to put pixels on a screen at the end of the day. So that's what wgpu does for me.
You do often need a graphics context to create the surface that displays the framebuffer.
Not necessarily.
Most desktop OS compositors provide a void** buffer that can be blitted to. Sure, this buffer will probably end up going through the compositor which does GPU hardware acceleration anyway, but it is definitely possible to shrink the application-side stack without relying on D2D/GLUT/GLEW/GLFW/SDL/WGPU in this case.
On Windows: CreateDIBSection and BitBlt
On macOS: CALayer and CATransaction commit
Not sure about Linux, too many stacks involved.
> Not sure about Linux, too many stacks involved.
Wayland: wl_shm and that’s it for the “stack”.
Cross-platform support can be more difficult in that case, but yes it is possible.