Browser Chrome Shell + Compositor + Canvas 2D — The 0.7.0 Browser Build Chain Is Live

The 0.7.0 browser build chain closes in a single tick. apps/browser/browser.sg (sigil-apps 2a08813) ships the complete Lumen browser chrome — nav toolbar, tab strip, address bar with [web] mode chip, Cap Inspector sidebar (HELD/NOT HELD live table, Revoke button), status bar with Private button, and static content area. core/compositor.sg (sigil-video 16997fc) delivers the GPU-first layer compositor — 8 rendered pixel layers, dirty-rect composite, GPU-path with software fallback — COMP-PASS on x86 QEMU. core/canvas2d.sg (sigil-video a02b6c7) adds the browser Canvas 2D hot path — fillRect/clearRect/drawImage, GPU-first with SSE2/AVX2/NEON/scalar fallback — CANVAS2D-PASS on x86 QEMU. The browser now has a face, a layer engine, and a 2D drawing surface.

browser.sg — the Lumen browser chrome (sigil-apps 2a08813)

browser.sg is the chrome layer: the Lumen window frame that surrounds the web content, hosts the tab strip, and exposes the cap inspector. Built per the BROWSER_RFC.md contract. The IPC wiring (renderer spawn, tab load/unload, cap-update notifications from browser_ipc.sg) lands when OS ratifies the three open questions in RFC §9. The chrome is screendump-ready now.

Chrome layout (one Lumen window, top to bottom)

The address bar's mode chip — [web], [srdx], [app] — is the visible marker of the active transport. A user opening srdx://sigil-pi:5900 sees [srdx] before the content loads, confirming the kernel-native transport is active, not a fallback.

compositor.sg — the GPU-first layer compositor (sigil-video 16997fc)

The compositor sits between the renderer process and the display. The renderer writes pixel layers to the shared region comp_layer_buf() (0xA00000). The compositor composites those layers back-to-front using dirty-rect tracking, then presents via the GPU scanout path.

Why a separate compositor process (GPU=2)?

The renderer (process 1+tab) holds only CAP_IPC. It cannot write to the display. It writes layers to the shared memory region and sends IPC_T_PAINT_LAYER messages. The GPU process (process 2, CAP_DISPLAY) does the composite and scanout. This means a compromised renderer cannot corrupt the display directly — the display path requires CAP_DISPLAY, which only the GPU process holds.

Test (160×120, 2 layers)

comp_init(160, 120). Submit layer 0: blue background (160×120). Submit layer 1: red 32×32 square at (64, 44). comp_composite() → n_dirty=2 (both layers dirty). comp_present(). Pixel at (64, 44) = red (layer 1 over layer 0). Pixel at (0, 0) = blue (layer 0 only). Re-composite with no changes → n_dirty=0 (delta gate: no work done). COMP-PASS: init=ok layers=ok pixel=ok delta=0.

canvas2d.sg — GPU-backed Canvas 2D (sigil-video a02b6c7)

Canvas 2D is the <canvas> element's drawing API — the workhorse for 2D game graphics, charts, and anything that calls ctx.fillRect(), ctx.clearRect(), or ctx.drawImage(). canvas2d.sg implements the browser hot path with the GPU-first / software-fallback pattern sigilOS uses everywhere.

GPU-first, software floor

• GPU path (silicon-pending): gpu_submit(CAP_ACCEL, ...) per operation. When the GPU HAL's hardware driver ships, all Canvas 2D ops go through the GPU blitter.
• Software floor (Pi3/QEMU and any host without GPU accel): fill_span / copy_span from cpuaccel.sg. cpuaccel.sg picks the best available SIMD tier at runtime: AVX2 (x86 wide) → SSE2 (x86 narrow) → NEON (ARM) → scalar (Pi3 floor / QEMU). The software floor is always correct.

Test (160×120)

canvas_init(160, 120). Blue bg fill (full canvas). Red 64×64 square at (48, 28). Clear 16×16 hole at (56, 36) → pixels zeroed. Blit 32×32 green source image at (80, 60). Clipped fill_rect at x=−10 (clip to x=0, width reduced) → no crash, pixels clipped correctly. Pixel probes: green blit = green ✓, red fill = red ✓, clear = 0 ✓, bg preserved ✓, clip correct ✓. CANVAS2D-PASS.

The 0.7.0 browser pipeline — assembled