What your graphics card does in webpaint.ing
By releases ·
webpaint.ing is the drawing and animation app that sits beside this site. It leans on your graphics card more than most web apps do. This note explains how, in plain words, and what is still done the slower way.
The foundation
- It draws with WebGPU. WebGPU is the browser's modern way of talking to the graphics card. The app does not fall back to the older WebGL, so a browser without WebGPU is told the app cannot run there.
- It is built on the WebGPU port of Godot by David Walter, with two small changes of about fifty lines in all. One of them is why the 3D reference model has a light. The engine read shadows in a way WebGPU refuses, so no lit 3D scene could appear in a browser. Reading them a different way fixed it.
Where your drawing lives
- Every layer of every frame is a picture held on the card. Strokes, fills and moves are drawn into it there, and the pixels are not copied into ordinary memory to be worked on.
- Reading pixels back from the card is slow, so the app does it only when it has to: saving, picking a colour, copying, and recording what a fill filled.
What the card draws
- Brush strokes go into a scratch picture that shows over your layer while you draw, then are laid onto the layer.
- Move, scale, rotate and warp treat the selected pixels as a fine grid stretched to four corners, which is why a warp bends smoothly.
What the card computes
Besides drawing, a card can run a compute shader: a small program that does plain arithmetic over a grid of numbers. The app has two.
- Fill and select by colour. One pass marks every pixel whose colour is close to the one you pressed. Sixteen sweeps then grow the area outward from that point, a whole row or column at a time. The result stays on the card and the fill appears from it straight away, so a big fill does not make you wait.
- Enlarging an export. Exporting at 2, 4 or 8 times the size makes each frame larger with sharp pixels. The method is tested against a known answer first, a card that gets it wrong is not used, and the Export window tells you which way was taken.
Not on the card yet
- The shape of a selection is still worked out in ordinary code, which is the slow part for a very large, ragged selection.
- A fill still reads its pixels back once, behind the picture you already see.
Moving both onto the card is the aim for very large canvases. Neither is built yet.