v0.1.4014 Nov 2026·Rendering, Web APIs & DOM

99% of real pages decided by the GPU

A quieter release you will not see but your machine will: 99% of what ordinary websites paint is now decided by the GPU, up from 94%, with every one of 25 recorded sites still byte for byte the software render. Enlarged images, shrunk backgrounds, radial and conic gradients and text in tight boxes all moved over, and the page you are reading looks exactly as it did. 9 changes, each with a law in the test gate, and one security fix a page could have used. The GPU row holds at 65 and the overall score at 74: the hard test corpus is still under its 98% bar.

Parity with the reference browser

74overall, as of v0.1.402

GPU / graphics acceleration65

Security architecture72

DevTools / extensions73

Web APIs / DOM surface75

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

99% of real pages, decided by the GPU

We count a page tile as the GPU's own only if the GPU worked out its colours, not if it merely copied colours the processor computed. On 25 recorded real sites that was 94%, and when we measured what held it back, one answer stood out: images. Enlarged images and shrunk backgrounds were 80% of the loss. A plain text page was the other surprise, stuck at 75% because of a guard meant for something else. With those moved over, plus radial gradients, the share is 99%, and not one pixel of those 25 sites changed from the software render. The test corpus of deliberately hard pages is at 96.8%, so we have not moved the score: 3D scenes and blend modes are still to come.

Real sites, colours decided by the GPU94.4% -> 99.1%Pixels that differ from software, 25 sites0Hard test corpus, same measure94.7% -> 96.8%Corpus raster time, processor vs GPU262 vs 136 ms

Whole numbers again

A GPU cannot be trusted to round decimals the way a processor does, which is why we keep removing decimals from the sums. Last release that was rotation. This time an enlarged image blends from an exact fraction, and a radial gradient's distance comes from a whole-number square root. Doing it in software too meant the new sums had to be no worse than the old, so we checked both against the reference: enlarged images came out a little closer, and gradients came out level.

Enlarged image, pixels off the reference by more than 218,306 -> 15,120Six gradient test pages, total difference from the reference17.225 -> 17.224A page of 400 different gradients317 -> 320 msA full-page gradient154 -> 150 ms

A size a page should not get to choose

Reviewing this work before release, we found the GPU path built its image tables for the image's whole box, so a page could write a width of a hundred million pixels and choose how much memory we asked for. An older path had the same flaw, and the software loop walked every off-screen pixel. All of them now cost only what lands on the canvas, and a law draws boxes up to 2 billion pixels wide and requires them to finish quickly with the right bytes.

Largest box in the law2,000,000,000 px

What changed 9 changes

Rendering	GPU: an enlarged image is blended on the GPU. The blend now works in whole numbers from an exact fraction, in software and in the shader, so every chip reaches the same bytes. It is also a little closer to the reference: on the test page the pixels more than 2 levels off went from 18,306 to 15,120.
Rendering	GPU: shrunk background images are drawn on the GPU, with the box filter plain images already used, repeats and rounded corners included.
Rendering	GPU: radial gradients are worked out on the GPU in whole numbers. Software and the shader share one table per column, one per row and a colour table, and take a whole-number root, so the result is the same bytes on the processor, Apple Silicon and DirectX 12. As close to the reference as before.
Rendering	GPU: conic gradients are drawn on the GPU as tables of colour runs, split at the centre column. Very saturated ones, where the colour changes on almost every pixel, stay in software.
Rendering	FIX: a glyph that pokes above its clip no longer draws one row twice. Its rows were rounded towards zero, so two of them landed on the top row.
Rendering	GPU: text in a tight box (overflow hidden) stays on the GPU. It was refused near the top of its own clip, so a page of plain text in table cells sat at 75% and is now 100%.
Rendering	Security: the tables for an image cover only what lands on the canvas. They followed the image's whole box, so a page could set an image a hundred million pixels wide and make the GPU path ask for hundreds of megabytes.
Rendering	Performance: software draws only the part of an image that lands on the canvas. It walked every pixel of the box, on screen or not.
Web APIs & DOM	FIX: a rounded image too big for exact corner sums (past a million pixels) is drawn by the exact software path, because corner distances stop being exact in that range.