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

Canvas drawing moves to the graphics card

Pages that draw with canvas (charts, games, editors, generative art) now keep their drawing on the graphics card: shapes, lines, sprites, all three kinds of gradient, clips, blend modes and shadows. Before this release only plain image draws went there, and any shape sent the whole canvas back to the processor. On our canvas benchmark every pixel is the same as the software canvas gives, on Mac and on Windows. That sameness is the point: a canvas that draws identical bytes on every graphics card cannot be used to fingerprint the card, which is what canvas fingerprinting scripts read. Correction (9 Nov 2026): this note first said the browser was faster than the reference browser on 9 of 11 benchmark rows, up to 19 times on full-screen fills. Those reference times came from an older version of the reference browser, measured on 4 Nov. Measured side by side with its current version, the browser is faster on 5 of 11 rows (full-screen fills, gradients, lines, text and reading pixels back) and slower on circles, sprites and shadows, which is the work that comes next.

Parity with the reference browser

75overall, as of v0.1.412

Security architecture72

DevTools / extensions73

Web APIs / DOM surface75

Networking85

Media85

Accessibility85

GPU / graphics acceleration95

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

Shapes on the graphics card, pixel for pixel

A filled shape or a stroked line becomes coverage: how much of each pixel the shape covers. The processor used to work that out for every pixel of the shape's box. Now it only cuts the shape's edges where they cross each pixel row, about one number per row, and the graphics card adds up the coverage inside each 16 by 16 tile itself. Every crossing has an exact whole-number form, so a tile can start in the middle of an edge and still get the processor's numbers, and there is no division on the graphics card (Apple GPUs get some whole-number divisions wrong next to loops).

5000 lines45 -> 17.6 ms60 big circles14.5 -> 3.2 msRandom shapes checked12,000 a run, 0 pixels differ

The graphics card and the page work at the same time

The canvas used to send a batch of drawing to the graphics card and wait for it to finish before recording more. Now a batch only waits for the one before it, so the card draws while the page's script records the next 256 draws. A small getImageData (a script reading a few pixels back, which many animations do every frame) now copies only those pixels off the card instead of the whole canvas.

Full-screen fills x10025.9 -> 3.6 msTurned sprites x200024.0 -> 5.8 ms

Gradients in whole numbers

A gradient's colour at each pixel came from floating-point maths per pixel: a division for linear gradients, a square root for radial ones, and the operating system's own angle function for cone-shaped (conic) ones, which can differ by a level between Mac, Windows and Linux. All three now come from whole numbers: an addition per pixel for linear, an exact whole-number square root for radial (circles sharing a centre), and our own angle table for conic. The processor and the graphics card compute the same colour, on every system. The colour picked is the same as before, or its neighbour in the 1024-step colour table (fewer than 1 pixel in 200 for linear, about 1 in 50 for radial, 1 in 100 for conic).

Full-canvas linear gradient x3048.0 -> 2.3 msRadial glows and fills92 -> 9.9 msConic fills184 -> 9.4 msSwitchesFLOATI_NO_CANVAS_FIXED_GRADIENT, _FIXED_RADIAL, _FIXED_CONIC

Clips, blend modes and shadows stay on the card

A clip, a blend mode other than normal, or a shadow used to send a graphics card canvas back to the processor. Clips now travel with the drawing, 18 of the 26 blend modes are computed on the card with the software's own whole-number maths (including copy and source-in, which change pixels outside the shape), and shadows and filters are made by the processor and laid onto the canvas by the card, so a page mixing sprites and shadows no longer bounces between the two.

2000 circles + 1000 sprites in a curved clip35.4 -> 14 ms a frame3000 additive particles + 500 multiply sprites45 -> 10 ms a frameSprites with shadows12 -> 5.2 ms a frame

What changed 27 changes

Rendering	Speed: canvas text composites four pixels at a time with the processor's vector instructions, the same bytes as before.
Rendering	Speed: fillText reads only the font box it needs instead of measuring the whole text.
Rendering	Speed: the glyph cache uses a faster hash, and pixels a glyph does not touch skip the blending sum.
Memory & reading	Speed: a text measurer remembers the glyph runs it has already put together, until a web font or the font list changes.
Rendering	Speed: fillText copies its text only when it has to.
Rendering	Speed: the vector composite uses widening multiplies and high-byte adds, fewer steps a pixel.
Tabs & interface	Speed: fillText reads the five text settings it uses instead of copying the whole state.
Rendering	Speed: a line of text placed wholly inside the canvas is used as its own mask instead of being copied.
Rendering	Speed: a text run blends only the stretches of each row that its glyphs cover.
Rendering	Speed: drawing in a solid colour allocates no row buffers.
Tabs & interface	Testing: a shape's coverage can be computed on the graphics card, proved equal to the processor's on 277 shapes on Mac and Windows; the base of what follows.
Tabs & interface	Speed (opt-in on Windows): the text composite has an SSSE3 form for Intel and AMD processors, the same bytes, faster text but slower full-screen fills, so it is off until that is understood. Switch: FLOATI_CANVAS_SSSE3=1.
Rendering	GPU: convex fills and strokes in a solid colour are drawn on the graphics card canvas from their edges, and a batch waits for the one before it instead of itself. Switches: FLOATI_NO_CANVAS_GPU_COVER, FLOATI_NO_CANVAS_OVERLAP.
Rendering	GPU: turned sprites take their coverage from the graphics card too, and batches are 256 draws so the card starts sooner.
Rendering	Speed: a small getImageData reads only its rectangle off the graphics card, and whole-pixel rectangles skip building coverage. Switch: FLOATI_NO_CANVAS_PARTIAL_READ.
Rendering	Speed: sprites at whole pixels send no coverage, and rectangles and sprites at fractional pixels send only their distinct rows. Switch: FLOATI_NO_CANVAS_COMPACT_ROWS.
Rendering	GPU: linear gradients are computed in whole numbers on the processor and on the graphics card, and a few big draws count like many small ones when choosing where a canvas lives. Switches: FLOATI_NO_CANVAS_FIXED_GRADIENT, FLOATI_NO_CANVAS_WEIGHTED_ATTACH.
Rendering	GPU: clipped drawing stays on the graphics card canvas. Switch: FLOATI_NO_CANVAS_GPU_CLIP.
Rendering	GPU: 13 blend modes (lighter, multiply, screen, overlay, darken, lighten, hard-light, difference, exclusion, xor, source-atop, destination-over, destination-out) are computed on the graphics card canvas. Switch: FLOATI_NO_CANVAS_GPU_MODES.
Web APIs & DOM	GPU: shadows and filters are laid onto a graphics card canvas instead of sending it back to the processor. Switch: FLOATI_NO_CANVAS_GPU_EFFECTS.
Rendering	GPU: copy, source-in, source-out, destination-in and destination-atop, which change pixels outside the shape, are computed on the graphics card canvas. Switch: FLOATI_NO_CANVAS_GPU_UNBOUNDED.
Rendering	Speed: drawing with no clip and no blend mode runs a smaller graphics card program, and tiles wholly inside a shape skip adding up their cells.
Rendering	GPU: radial gradients whose circles share a centre are computed in whole numbers, with an exact whole-number square root, on the processor and on the graphics card: 92 -> 9.9 ms on the graphics card canvas, 92 -> 55 ms on the processor. Switch: FLOATI_NO_CANVAS_FIXED_RADIAL.
Web APIs & DOM	Speed: shadows, filters and shaded images blend four pixels at a time with the processor's vector instructions: shadows 2.3 -> 1.9 ms. Switch: FLOATI_NO_CANVAS_ROW_SIMD.
Rendering	GPU: conic gradients take their angle from our own table instead of the operating system's, so every system and graphics card gives the same pixels, and the graphics card computes them itself: 184 -> 9.4 ms there, 184 -> 98 ms on the processor. Switch: FLOATI_NO_CANVAS_FIXED_CONIC.
Web APIs & DOM	FIX: a canvas busy on the graphics card while the window was resized could make the window give up on the graphics card for the rest of the session, which made heavy pages drop to a few frames a second. Canvas work now waits its turn while the window resizes.
Rendering	Testing: the canvas checks run 12,000 random shapes, clips, blend modes, gradients, turned sprites, small reads and a lost graphics card, each compared byte for byte with the software canvas, on an Apple GPU and an NVIDIA one.