v0.1.4024 Nov 2026·Rendering, Web APIs & DOM, Memory & reading, Tabs & interface

A canvas that moves itself to the GPU

Canvas games and busy drawing pages now run on the GPU: 1500 turning sprites went from 38 to 62 frames a second at the same memory, with every pixel the same bytes as the software canvas on Apple Silicon and DirectX 12. A canvas shadow drawn again is about five times faster too. 8 changes, each with its own off switch or a law in the test gate. The GPU row holds at 65 and the overall score at 74: shapes and text on a canvas still run in software.

Parity with the reference browser

75overall, as of v0.1.405

Security architecture72

DevTools / extensions73

Web APIs / DOM surface75

GPU / graphics acceleration77

Networking85

Media85

Accessibility85

Real-world site compatibility99

HTML parsing100

CSS parsing + selectors100

Layout: block / flex / grid / tables / writing-modes100

Paint + visual100

JavaScript language100

JavaScript performance (JIT)100

HTML parsing100

A canvas that moves itself to the GPU

A canvas page can read its own pixels at any moment, so the GPU's answer has to match the software's exactly, or a script sees something different depending on which one drew. That is why we rewrote image sampling in whole numbers first. Then came the part a page should never notice. Draws now wait in a list. A canvas that draws many images moves to the GPU, and a canvas that turns to shapes moves back, because software still draws those faster. Anything that reads the canvas finishes the list first. A law runs random drawing on both and compares the bytes every round, on Apple Silicon and on DirectX 12. In the app, 1500 turning sprites went from 38 to 62 frames a second at the same memory.

1500 turning sprites at 1280x720, frames a second38 -> 62Time for one frame25.5 -> 13.8 msBrowser memory on that page333 -> 335 MBPixels that differ from software0

Faster, and why we are not done

Against the reference browser this is a mixed result, so here it is plainly. On the benchmark's 11 rows, the same bytes come out of our GPU and our software on every row. We are ahead on fullscreen fills and on reading pixels back. The reference's GPU is still ahead on scaled and rotated sprites, and its software is ahead on shapes, lines, gradients, text and shadows. Moving shapes and text over is next, and the GPU row of the score stays at 65 until that work is measured.

Scaled sprites x500061.7 -> 15.2 ms (reference 7.4)Rotated sprites x200054.7 -> 25.1 ms (reference 4.3)Fullscreen rectangles x10030.8 ms (reference 68.3)Reading a full canvas x2012.4 ms (reference 14.7)

The same shadow, once

Blurring a shadow is the slow part of drawing it, and a page often draws the same one many times. A canvas now keeps its last 8 finished shadows, up to 1 MB each, and compares the whole shape before reusing one. We kept this per canvas on purpose. A cache shared across pages would let one page time what another has drawn, and the speed is not worth that.

200 shadows16.5 -> 3.2 msShadows kept per canvas8, at most 1 MB each

What changed 8 changes

Memory & reading	Canvas: a canvas remembers the shadows it has finished, so the same shadow drawn again costs a copy, not another blur: 16.5 -> 3.2 ms on the test, the same bytes. The memory is per canvas and never shared, so one page cannot time what another has drawn.
Rendering	Performance: a glyph drawn to the right of the text so far is copied instead of blended, which is what most of a line of text is.
Rendering	Performance: canvas blending does runs of full coverage four pixels at a time, with the same bytes.
Rendering	Canvas: a low-quality image draw finds its texels in whole numbers from its own corner. It used decimals, which a GPU cannot be trusted to round the same way, and it is level with the reference browser.
Web APIs & DOM	GPU: canvas image draws are sampled on the GPU in the software's whole numbers, the same bytes: 5000 scaled sprites 60.8 -> 11.5 ms with a read-back on every frame.
Web APIs & DOM	GPU: a busy image canvas moves to the GPU by itself and comes back when it starts drawing mostly shapes, which software still does faster. Draws wait in a list, and everything that reads the canvas finishes them first, so a script can never see a half-drawn frame. Sprites at their own size 14.9 -> 11.7 ms, rotated 54.7 -> 25.1 ms, scaled 61.7 -> 15.2 ms.
Memory & reading	Security: limits on what a page can make the GPU do: 4096 operations, 32 MB and 2^26 pixels in a batch, 64 MB of GPU memory per canvas and 512 MB in total. A batch waits for the last one to finish, so a page cannot pile work on the shared device.
Tabs & interface	Testing: the Windows stage now fails instead of skipping if the live canvas law finds no GPU, and that law was seen running on DirectX 12.