WebGL2 Puppeteer Setup and Testing for 058-Microcosm

Let me think about this. The task says "Wake up and do as you please." The previous execution created Demo 057 (Basin Fractal). So I should create a new demo — Demo 058 — something impressive with Three.js.

Let me check the current state of the demos folder first, then create a new advanced demo.

Let me install shell tools first.

Let me look at the current demos folder to see what exists.

There are 57 demos. I need to create Demo 058. Let me think about what would be a cool, advanced demo that hasn't been done yet. Let me review what's been done:

• 001 spinning cube, 002 nebula galaxy, 003 mandelbulb, 004 fluid dynamics, 005 gravity sandbox, 006 event horizon (black hole), 007 sonic reactor (audio), 008 void runner (game), 009 azure odyssey, 010 abyssal bloom (underwater), 011 physarum (slime mold), 012 powder alchemy (falling sand), 013 clockwork nebula, 014 neon rain, 015 aurora, 016 skitter (creatures), 017 coral resonance, 018 threshold, 019 attractorium (strange attractors), 020 murmuration (flocking), 021 terraforge (terrain), 022 cloudsea (clouds), 023 frostline, 024 koi pond, 025 ferrofluid, 026 synchrony (coupled oscillators?), 027 cymatics, 028 teslasphere, 029 pyrosymphony, 030 morphogenesis, 031 galton cascade, 032 wavefront, 033 gossamer, 034 magnetosphere, 035 cloud chamber (particle physics), 036 wavefunction (quantum), 037 epicycle, 038 sandpile, 039 kinetic theory (gas), 040 lumen lab (optics?), 041 squish lab (soft body), 042 neon tilt (game), 043 hyperfold, 044 photon garden, 045 critical point (phase transition/ising?), 046 bridge works, 047 primordial, 048 coasterworks (roller coaster), 049 sakura grove, 050 voxelia (voxels), 051 neon district (city), 052 supercell (storm), 053 caldera (volcano), 054 domino rally, 055 phantom jam, 056 wavewalker (wave surfing?), 057 basin (magnetic pendulum fractal).

Ideas for demo 058 that haven't been done:

• Kaleidoscope / hyperbolic tiling (Poincaré disk) — hyperbolic geometry!
• Reaction-diffusion (Gray-Scott) — wait, 030 morphogenesis might be that. Let me check.
• Maze generation / 3D maze
• Cloth simulation — 041 squish lab is soft body
• Fire/fluid — done
• Lightning — teslasphere
• Ocean with Gerstner waves — 056 wavewalker is wave surfing
• L-systems / procedural trees — sakura grove is trees
• Lightning bolts
• Double pendulum chaos
• Spirograph — epicycle
• Particle life (artificial life with attraction/repulsion rules) — that's a good one! "Particle Life" — clusters of colored particles with simple attraction/repulsion matrices producing emergent behavior. Not done yet I believe. Physarum is different (agents on trail map).
• Hyperbolic tiling explorer (Poincaré disk with {7,3} tiling, Escher-like) — very cool, shader-based.
• Voronoi / Delaunay art
• Boids — murmuration done
• Game of Life 3D
• Ant colony
• Lightning
• Orbital mechanics / n-body — gravity sandbox done
• Lissajous
• Tesseract / 4D — hyperfold might be that
• Ray marching — mandelbulb done, threshold might be raymarched

"Particle Life" is a great candidate — it's visually mesmerizing, interactive (edit attraction matrix), self-running emergent art. GPU-based with instancing, can do thousands of particles.

Another great candidate: hyperbolic Poincaré disk tiling with animated geodesics — shader-heavy and unique.

Let me check what a few demos actually are to avoid duplication. Let me quickly grep the index.html for descriptions.

I've seen all 57 demos. Notable gaps I could fill:

1. Particle Life (attraction/repulsion matrix artificial life) — NOT done. Physarum is slime mold (different). This would be a great one.
2. Hyperbolic tiling (Poincaré disk) — NOT done. Very shader-math heavy.
3. Double pendulum chaos — basin was magnetic pendulum fractal, so pendulums are a bit covered.
4. Lightning — covered in multiple.
5. Ant colony — not done, but physarum is similar conceptually.
6. Game of Life / cellular automata — Lenia done (primordial), so CA is covered.
7. Mandelbrot/Julia explorer — mandelbulb is 3D; a 2D deep-zoom Mandelbrot with smooth coloring could be cool but maybe less "3D wow".
8. Voronoi/Delaunay — not done.
9. Cloth/flag — soft body done (squish lab), cloth bridge done.
10. Kuramoto on a sphere — synchrony covers fireflies.
11. Turing patterns — morphogenesis done (Gray-Scott).
12. Light-based plant growth / DLA (diffusion-limited aggregation) — DLA not done! Could be a 3D DLA crystal growth... frostline is snow crystal (similar to DLA).
13. Particle Life — I think this is the winner. It's a well-known mesmerizing system: multiple species (colors) of particles, each pair of species has an attraction/repulsion rule in a matrix, simple force laws produce emergent cells, hunters, spirals, membranes, etc. Can do GPU GPGPU O(n²) like murmuration did boids. Interactive: click to attract/repel, randomize matrix, adjust parameters, palettes.

Actually wait — murmuration (020) was GPU boids O(n²) in fragment shaders. Particle Life would use similar GPGPU infrastructure but the emergent behavior is very different — species-based attraction matrices create "artificial life" with cell-like structures. I can make it visually distinct: 2D top-down with glowing orbiting particles, maybe rendered in 3D with a tilted plane + bloom.

Alternatively Hyperbolic Poincaré tiling would be extremely unique and math-heavy: raymarched/shader Poincaré disk with {p,q} tiling, animated Escher-like patterns, fish swimming along geodesics, zoom into the disk, morph between tilings. That's never been done in the collection. It has a huge "wow" factor and is quite different from everything else.

Let me decide: I'll do Particle Life — it's a crowd-pleaser, very "alive", and with good GPGPU work it'll look amazing with trails and bloom. Actually, let me think about which one will be more impressive and reliable to implement in one shot.

Particle Life details:

• N species (e.g., 6), each with a color.
• Force matrix F[i][j] in [-1, 1].
• Force law: for distance r < r_max: if r < beta: repulsion (r/beta - 1); else attraction * (1 - |2r - 1 - beta| / (1 - beta)) peak at mid.
• Velocity damping (friction).
• Wrap-around torus world.
• GPGPU: positions+velocities in float textures, O(n²) fragment-shader force computation — like murmuration did. 4096 particles = 64×64 texture; O(n²) = 16.7M pair checks per frame per texture read — fine on GPU, but in headless llvmpipe testing it may be slow. Murmuration did 9216 boids, so it's feasible.
• Interaction: mouse attractor/repeller; randomize rules button; presets (known interesting matrices); parameter sliders (beta, r_max, friction, force factor); trails via accumulation buffer (like attractorium); bloom.
• Audio: generative pad that reacts to cluster energy.

The murmuration demo already did "GPGPU boids O(n²) in fragment shaders" — using a similar technique for particle life is fine since the behavior/visual is completely different (that was 3D flocking birds with wing flapping; this is 2D primordial-soup artificial life).

Alternatively hyperbolic tiling: full-screen fragment shader, Poincaré disk, render {p,q} tiling via reflection group (fold space into fundamental domain), animated colors, Escher "Circle Limit" fish option is too hard; but tiling + geodesics + horocycles is doable. Controls: morph p and q, animate zoom via hyperbolic translation (Möbius transform), click to recenter (translate point to origin). Add a little 3D framing in Three.js — a disk floating in 3D space with bloom. It's beautiful but maybe less "alive".

I'll go with Particle Life — it's emergent, alive, interactive, and unique vs. the rest of the collection. Actually, hold on, let me reconsider: is there anything like it? 011 physarum = agents + trails (slime mold) — produces networks. Particle life produces cell-like blobs, hunters, etc. Distinct enough. 047 primordial = Lenia continuous CA — cellular blobs! Lenia does look similar-ish (blobby creatures), but it's a CA, not particle-based. Hmm, Lenia is "bioluminescent petri dish... continuous cellular automaton... soliton life". Particle life's emergent cells would visually echo that a bit. But the mechanism and aesthetics (thousands of discrete glowing organisms, species colors, trails) differ.

What about Hyperbolic geometry explorer? Nothing like it in the collection. Math wow factor is high, shader-heavy, and I can add animation (geodesic flow, translating through the tiling = "flying through hyperbolic space"), plus clicking to recenter, plus polygon count (p,q) morphing. Include horocycles/flower patterns, spectral colors, fish-like motifs? Keep it clean: animated Circle-Limit-style tiling with color cycling, hyperbolic translation driven by velocity, a "tilt" 3D view with the disk as a glowing object, bloom.

Hmm, both are good. Decision: I'll do Particle Life ("Primordial Soup" style). Reasons: emergent behavior = high wow; interactive rule-matrix editing is unique; performance manageable; distinct enough from Lenia (discrete swarm vs. field).

Hmm, wait. Actually, let me reconsider hyperbolic once more... The collection has a LOT of particle systems (murmuration, attractorium, galaxy, fireworks, cymatics...). A hyperbolic tiling explorer would stand out as totally different. But its interactivity is a bit more limited, and the visual is 2D-ish. I can make it a 3D scene: the Poincaré disk as a physical artifact — a glowing "hyperbolic lens" floating in a dark studio, with the shader on the disk surface, slowly rotating, bloom, reflections. Plus animated flight through the tiling. That's a great blend.

Let me think about what's more robust to implement correctly in one pass without visual debugging... Actually I CAN debug: last run set up Puppeteer + Firefox headless with Mesa. I can screenshot and iterate. Great — either is feasible.

Let me go with Particle Life but make it spectacular:

• Title: "058 — Microcosm" or "Primordial" (taken) / "Microbia" / "Zoon" / "Petri" / "Vitalis" / "Soup" / "Microcosmos". Name idea: "microcosm" — folder 058-microcosm. Title: "Microcosm — Particle Life". Hmm "Primordial" was Lenia. "Microcosm" is good.
• 6 species, 6000 particles (or 4096 for perf; maybe scale by quality tier: 1024/2500/6400... 80×80=6400).
• GPGPU ping-pong: positions texture + velocities texture (or combined: xy=pos, zw=vel in one RGBA32F texture!). Single texture holds both — simpler: one texture RGBA32F: xy = position, z... wait need velocity too: use two textures or pack pos+vel into one RGBA (x,y pos, z,w vel) — yes! RGBA32F: (px, py, vx, vy). Single ping-pong pair, one update pass. O(n²) inner loop in fragment shader reading the previous state texture.
• Species ID: pack into... we need species per particle — could derive from particle index: species = index % S or index / (N/S). Deriving from index is clean and doesn't need storage. Species color in render shader from index too.
• Force matrix: 6×6 = 36 floats → uniform array, settable from JS.
• Boundary: torus wrap. But with wrapping, force computation needs minimum-image convention (9 copies check). In shader, for each neighbor compute d = b - a; d -= worldSize * round(d / worldSize); — minimum image. That works on a torus as long as r_max < worldSize/2. Good.
• Physics substeps maybe 2 per frame.
• Rendering: points with instanced quads? Use THREE.Points with custom shader, size attenuation off (2D ortho-ish look) — or a slightly tilted 3D perspective camera looking at a plane. Particles as soft glowing discs (SDF circle in fragment shader via gl_PointCoord). Additive blending + bloom.
• Trails: screen-space accumulation feedback buffer (like attractorium): render particles to a trail buffer, fade previous frame, then composite to screen with bloom.
• Interaction: pointer = attract/repel vortex (hold shift/right-click to repel); click-drag to stir; buttons: New Universe (random matrix), presets (known good ones: "Cells", "Hunters", "Chaos", "Symbiosis", "Snakes"...), sliders: force radius, beta (repel zone), friction, force strength, number of species (2-6) maybe. Palette cycling.
• HUD: rule matrix visualization (6×6 colored grid canvas, editable? maybe click cells to cycle values — could be complex; simpler: show matrix as colored grid, click a cell to randomize that row? Let me make cells clickable: click = +0.25 step, right-click = -0.25, showing value as hue. That's a nice touch but adds complexity. Maybe just display-only grid + "randomize" — but editable matrix is a killer feature. Let me do: click cell to cycle through values [-1, -0.5, 0, 0.5, 1] with live update. Actually drag on cell vertically to set value — hmm, keep it simple: left-click +, right-click −, step 0.2. Show numeric on hover tooltip. OK.)
• Audio: generative — soft pad + per-species plink when clusters form? Simpler: ambient drone whose chord follows cluster entropy; clicks when you randomize. Toggle with button, off by default (browser autoplay policy anyway — start on first interaction).
• Stats: FPS, particle count, population diversity (species population share bars? populations are fixed per species though — since species is by index, counts are fixed. Instead show "activity" — mean speed.)
• Quality tiers: low 1024 (32×32), medium 2500 (50×50), high 6400 (80×80)? O(n²): 6400² = 41M pair-evaluations per step — that's heavy but murmuration did 9216² = 85M on GPU. For llvmpipe testing it'll crawl, but that's just for validation. Let me pick 64×64=4096 high tier. With float texture requirement: need WebGL2 + EXT_color_buffer_float for RGBA32F render targets. Murmuration did GPGPU already so the environment presumably supports it; Firefox+Mesa supports EXT_color_buffer_float. I'll include fallback to half float.

Also a wrap check: r_max (interaction radius) ~ 60-80 in world units of, say, 800×600? Or normalized world [-1,1] with r_max ~0.08.

Let me design the force law precisely (from the classic "Particle Life" by Tom Mohr / Jeffrey Ventrella clusters):

where r normalized by r_max, a = attraction factor from matrix [-1,1].

Force on i from j: F = f(r/rmax, a[si][sj]) * strength; direction along d.

Velocity: v = (v + F * dt) * friction^(dt)... classic: v *= (1 - friction); v += F * dt * dt? Various forms. I'll use:

• accel = sum over j of dir * f(r) * a[si][sj]
• v = (v + accel * forceFactor * dt) * damp, damp = exp(-friction * dt)
• pos += v * dt; wrap.

Beta ~ 0.3, r_max ~ 0.05-0.12 (normalized), forceFactor ~ tuned.

Presets: I'll hand-craft a few matrices known to produce cells/hunters. I can also generate random with biases. Known good behavior often from random matrices with asymmetric entries. I'll include: "Genesis" (random asymmetric), "Symbiosis" (symmetric-ish), "Predators" (cyclic predator-prey: species i attracted to i+1, repelled by i-1... actually hunters: i attracted to i+1 (chases), i+1 repelled by i (flees) → cyclic chase), "Cells" (strong self-attraction with tight beta), "Mitosis", "Turbulence".

Cyclic chase matrix: A[i][i+1] = +0.8 (i chases i+1), A[i+1][i] = -0.6 (i+1 flees i). Plus self-attraction +0.3, self short-range repulsion handles clumping. This creates rotor-like chasing — very alive.

Cells: A[i][i] = +1, beta small (0.2), strong force; cross-terms small negative.

Alright — visual style: dark petri-dish / microscope vibe? A glowing dark teal background, particles as bioluminescent organisms with trails, subtle vignette, bloom. Camera: mostly top-down 2D with slight 3D tilt option? Simpler: full-screen 2D with WebGL ortho quad; but guidelines say Three.js scene — I'll use an orthographic camera, quad rendering for simulation/composite passes via THREE, which is fine and standard for GPGPU demos. Add a slight parallax background (procedural nebula-ish gradient, floating dust) for depth. And a petri-dish rim? The torus world has no edges; a rim would be misleading. Skip rim; full-bleed world.

Composite pipeline:

1. Update pass: state texture (ping-pong) — fragment shader loops all N particles.
2. Trail pass: fade previous trail texture (draw fullscreen quad with trail texture * decay) then render particles as additive points into it. Two steps: (a) fade quad into trail buffer, (b) draw points into trail buffer with additive blending.
3. Composite to screen: fullscreen quad sampling trail texture with tonemap/palette/vignette/grain. Then EffectComposer with UnrealBloomPass on the final? Bloom on top of composite: render composite to a render target, then composer passes (bloom + final grade). Or simpler: composite into composer chain: RenderPass rendering the composite quad scene → UnrealBloomPass → OutputPass-ish grade shader.

Simpler structure: main scene = ortho camera + fullscreen quad whose shader combines: background gradient + trail texture (tonemapped) + vignette/grain. Render via EffectComposer: RenderPass(mainScene) → UnrealBloomPass → ShaderPass(grade: ACES + vignette + grain + chromatic aberration). That's clean and mirrors prior demos.

Pointer interaction in torus world: map screen → world coords (ortho). Pointer applies radial force field (attract with left button, repel with right/shift). Also add "stir" — inject velocity tangentially. Keep attract/repel.

UI: top-left title, bottom control bar: buttons [New Rules] [Preset ▾] [Pause] [Audio] [Snapshot]; sliders: Radius, Beta, Friction, Force, Trails. Matrix grid top-right (S×S) with hover labels "Red → Cyan: +0.4". Species legend.

Nice extra: population graph? Skip. Activity meter (mean speed) as small bar — cheap, add.

Audio: WebAudio generative — start/stop toggle. Two detuned saws through lowpass + slow LFO, plus per-frame probability plucks scaled by activity. Keep it simple and robust.

Snapshot: canvas toDataURL download — needs preserveDrawingBuffer or render-on-demand; with composer, easiest: after render in same frame, canvas.toBlob. Use preserveDrawingBuffer: true (slight perf cost, fine) as prior demos did.

Adaptive quality: monitor FPS; tiers: high (64×64=4096), medium (48×48=2304), low (32×32=1024). On tier change, re-init state textures. llvmpipe test will be slow — that's okay, test with low tier forced via URL param (?q=low) maybe.

Now about verifying: I'll write the file, then run a headless Firefox Puppeteer test: load page, wait a few seconds, capture screenshot, check console errors, click "New Rules", check pixels not black and colorful. Use the same setup as last run (need to check if the environment still has firefox/puppeteer installed — the sandbox may be fresh each run; check).

Let me check the existing 057 demo for conventions (script src of three, import map, how they structured). Let me look at the 057 file quickly and the index.html structure around the card list to insert my new card in the right place.

Node exists but puppeteer isn't installed in this environment (fresh env each run). Firefox not found at /usr/bin. I'll need to reinstall: apk add firefox (Alpine) or check. Last run did: install Firefox with Mesa. Let me check the OS and what's available.

Alpine, fresh environment. I'll write the demo first, then set up Firefox + puppeteer-core for validation (install in background while writing? No — write first, it's the main artifact).

Let me now write the full demo. I'll create /space/demos/058-microcosm/index.html.

Key design decisions finalized:

• Folder: 058-microcosm, Title: "Microcosm — a particle-life soup".
• GPGPU single RGBA32F state texture (px,py,vx,vy), ping-pong.
• Species from particle index (even split). MAXS=8 species cap; active S selectable.
• Force matrix uniform float[64]; JS keeps Float32Array.
• Update shader: O(N²) minimum-image torus forces, particle-life kernel, pointer force, damping, wrap.
• Trails: ping-pong trail textures; fade pass + additive points pass.
• Background: procedural shader quad (deep ocean gradient + faint fbm + dust motes with parallax).
• Composer: RenderPass(scene) → UnrealBloomPass → grade ShaderPass (ACES, vignette, grain, chromatic aberration, saturation).
• UI: title panel, controls (sliders: force, radius, beta, friction, trails, species), buttons (New Universe, preset chips, pause, audio, snapshot, quality), rule matrix grid (click +0.2 / right-click −0.2, hover tooltip with species names), legend dots, stats (fps, mean speed, entropy, world pop).
• Presets: Genesis (random asym), Cells, Hunters (cyclic chase), Symbiosis, Metabolism? Keep 5: GENESIS/CELLS/HUNTERS/SYMBIOSIS/VORTEX? I'll do genesis, cells, hunters, symbiosis, chaos.
• Audio: generative pad + plucks, toggle.
• Quality: ?q=low|med|high; auto adaptive; particle tex 32²/48²/64².
• Snapshot: preserveDrawingBuffer true, toBlob download.

Species palettes (base hues): I'll define palettes array of 8 hues per palette; 3 palettes: "biolume" (teal/cyan/green/violet/amber/pink...), "ember", "abyss". Colors via HSL→RGB in shader? Simpler: pass 8 colors as uniforms (vec3). Update on palette switch.

Preset matrices — let me design them as JS arrays of arrays (8×8 but only S×S used; fill rest 0). For S=6 default.

GENESIS: random in [-1,1], diagonal biased +0.4..1, off-diag ±; zero small values? Keep continuous.

CELLS: diag +1; off-diag random small ±0.3, some +0.6 links. beta 0.18, radius lower (0.05), force high.

HUNTERS: cyclic: A[i][i]=0.5; A[i][(i+1)%S]=0.9 (i attracted to next); A[i][(i+S-1)%S]=-0.7 (i repelled by previous) → cyclic pursuit; plus small random. Higher friction (calm), radius 0.08.

SYMBIOSIS: pairs: A[0][1]=A[1][0]=0.8; A[2][3]=...; A[4][5]=...; diag 0.6; cross between pairs -0.2.

CHAOS: fully random ±1 asymmetric, higher force, more friction.

I'll write a helper makeMatrix(fn).

Tooltip: div absolute, updated on mouseover of cells.

Matrix cell rendering: 8×8 grid, each cell background color computed: v>0 → green/cyan intensity, v<0 → red/magenta. Row/col headers colored squares. Also highlight row+col on hover. For species > S active: dim them.

Now let me also double check one subtle thing in the update shader: textureSize(uState,0) returns ivec2; loop bounds must be constant-ish for GLSL ES 3.0 — for loops with dynamic bounds are allowed in ES 3.0. Fine.

texture(uState, uv) — state texture filter nearest.

Ping-pong: simRT[2], index swap. Initial: fill Float32Array with random pos/vel, create DataTexture, then blit into RT? Easiest: renderer.copyTextureToTexture or just create the first RT by rendering an init quad; simpler: create THREE.DataTexture and use it as the starting "read" texture — but ping-pong expects to render INTO the other RT. Frame 1: read = dataTexture, write = rt[0]; frame 2: read = rt[0], write = rt[1]... but rt[1] never got data on frame 1 — fine, write targets alternate; read alternates too. So read sequence: dataTex, rt0, rt1, rt0... Actually standard: cur = dataTex; each frame: render update into rt[writeIdx], then cur = rt[writeIdx], writeIdx ^= 1. That works — rt[1] gets written on frame 2 before being read on frame 3.

Reset: regenerate dataTex (dispose old), cur = new dataTex, writeIdx = 0, clear trails.

Trail fade: shader samples trailPrev with decay; also slight diffusion blur for glow spread? Keep pure decay + small blur via 4 taps — adds softness. I'll add a tiny 4-tap blur (offset 1.5px) to get nice diffusion.

Trail render: first fade pass into trailWrite (reading trailRead), then render points into trailWrite with additive blending (no depth). Swap.

Points vertex shader needs uState texture read (WebGL2 supports texelFetch in vertex shader) and gl_PointSize.

Composite quad in main scene: ShaderMaterial with uniforms tTrail, tBackground procedural params (time), tonemap inside grade pass instead. Composite quad outputs: bg + trailColor * exposure. HDR-ish values → bloom threshold picks bright cores.

Grade pass: ACESFilmicToneMapping approximation, vignette, grain, chromatic aberration, saturation boost. Composer's OutputPass would do tone mapping+sRGB; I'll do custom grade that ends with sRGB conversion manually (LinearToSRGB). Since renderer.outputColorSpace with composer render targets — to avoid color space confusion: set composer render targets type HalfFloatType; final grade shader does color = pow(color, vec3(1.0/2.2))? Cleaner: include #include <colorspace_fragment>? In a ShaderPass material, chunks work if compiled... Simplest: do gamma in grade shader manually. Set renderer.toneMapping = NoToneMapping.

Actually wait — EffectComposer renders to HalfFloat RT by default in recent three (r160 uses HalfFloatType default). Output color space conversion happens only if OutputPass used. I'll implement my own final conversion in grade shader. Good.

Now, stats: mean speed + entropy via periodic GPU→CPU readback (readRenderTargetPixels every 30 frames into a reused Float32Array; RGBA32F readPixels should work on Firefox/Chrome with EXT_color_buffer_float; wrap in try/catch; if fails, show "—"). Also compute per-species histogram for legend bars? Population counts fixed... but I could count "active" (speed above threshold) per species — fun: legend shows activity bars per species! Nice touch: bars under each legend dot showing current mean speed of that species. Cheap from same readback.

Entropy: shannon entropy over grid occupancy.

HUD updates throttled to 2/s.

Audio (module):

• ctx lazily created on first toggle; master gain.
• Pad: 3 oscillators (saw detuned) → lowpass(400Hz) → slow LFO on cutoff (0.05Hz, depth 200) → gain 0.05 → master. Chord changes every ~8s cycling through nice progressions (e.g., Am9, Fmaj7, Cmaj9, G6...): set osc freqs with exponentialRamp.
• Plucks: on random timer ~ every 0.4-2s scaled by activity: osc sine freq from pentatonic, gain env exp decay, into convolver? Skip convolver; use feedback delay: delayNode 0.31s feedback 0.35 wet 0.3.
• Interaction blip on matrix edit; whoosh on new universe (noise buffer bandpass sweep).
• Activity drives pad brightness (lowpass cutoff base) — set from main loop each second. Keep ~120 lines.

Autoplay policy: audio only starts on user toggle (button) — good; also start on first pointerdown if toggle on? Default OFF; user clicks AUDIO.

Snapshot: composer.render() then canvas.toBlob → a.click. preserveDrawingBuffer:true.

URL params: ?q=low|med|high, ?s=species? minimal.

Keyboard: space pause, N new universe, A audio, 1-5 presets, P snapshot, Q quality cycle.

Touch: pointer events unify; slider inputs fine; matrix cells small on mobile — hide matrix panel on narrow screens (media query) like 057 hid panels.

Fallback: if !WebGL2 or no EXT_color_buffer_float → show #fallback message.

Edge case: Firefox llvmpipe supports EXT_color_buffer_float — yes.

HalfFloat fallback: skip, just require float; show fallback otherwise.

Now write the code. It'll be long (~1100 lines with comments). Let me be meticulous.

Shader details:

Update fragment shader:

Hmm wait — gl_FragCoord in GLSL3 fragment for out vec4 — fine, use out vec4 fragColor; declared; three's ShaderMaterial with glslVersion: THREE.GLSL3 handles texture() etc. Actually with raw ShaderMaterial + glslVersion GLSL3, three prepends precision etc? For ShaderMaterial, three prepends built-in uniforms and #version when glslVersion set. It also declares out highp vec4 pc_fragColor and defines gl_FragColor as pc_fragColor! Yes — three's WebGLProgram adds #define gl_FragColor pc_fragColor for GLSL3 materials, and declares the out var automatically. So I should NOT declare my own out vec4 (would conflict) — use gl_FragColor. Let me recall exactly: in WebGLProgram.js, for fragment shaders with GLSL3: it prepends layout(location = 0) out highp vec4 pc_fragColor; #define gl_FragColor pc_fragColor. Yes. So write shaders with gl_FragColor and texture() — works.

Also vUv varying: ShaderMaterial doesn't auto-add attributes except position/uv/normal when... For fullscreen quad using THREE.PlaneGeometry(2,2), attribute uv exists; declare varying vec2 vUv; in both shaders, vertex: vUv = uv; gl_Position = vec4(position.xy, 0.0, 1.0); — with ShaderMaterial, position/uv attributes are declared automatically (three prepends attribute declarations for position, normal, uv). Yes, standard.

texelFetch with sampler2D in GLSL3 — ok.

int(mod(float(idx), uSpecies)) — uSpecies float uniform; fine.

Matrix uniform as float array: uniform float uMat[64]; set via value = Float32Array(64) — three handles arrays of floats for uniform float[]? For uniform float array, value should be a flat array; three's UniformUtils: for float uMat[64], setValueV1fArray — accepts Float32Array or regular array flattened. Yes.

Performance: inner loop N iterations with texelFetch each. 64²=4096 particles → 4096² = 16.7M texelFetches per sim step; 2 substeps = 33M — heavy for llvmpipe (test) but GPUs fine. For test, use ?q=low (32²=1024 → 1M fetches ×2 = 2M — llvmpipe can do a few fps).

Points vertex shader:

Points geometry: BufferGeometry with position attribute = texcoords (i%tx+0.5)/tx... I'll store texcoord in position.xy (z=0) and also in uv? ShaderMaterial declares both position and uv; I'll fill position with (u,v,0) and use position.xy as the texcoord, and compute clip position manually:

Points fragment:

Additive blending, depthTest false.

Trail fade shader:

Composite shader (main scene quad):

Background: deep teal-navy gradient + slow fbm clouds + faint dust:

Grade pass:

Standard.

Matrix UI generation: species colors as CSS hex matching shader colors.

Palettes (8 colors each, but first 6 used by default):

• biolume: ['#ff5a5a', '#ffc357', '#7dff6a', '#3ee6c4', '#59a7ff', '#c08bff', '#ff6ad5', '#ffffff'] — hmm keep cohesive: red, amber, lime, teal, azure, violet, magenta, white.
• prism: classic rainbow saturated.
• ember: warm set (red/orange/amber/gold/coral/rust...) — 8 warm shades. Colors passed as vec3 uniforms (linear-ish; I'll use them raw as HDR-ish emissive).

Preset matrices as functions:

Let me define concrete matrix builders:

Per-preset default physics params:

• genesis: radius 0.055, beta 0.30, force 1.0, friction 4.0
• cells: radius 0.045, beta 0.22, force 1.2, friction 3.0 (tight clumps)
• hunters: radius 0.08, beta 0.35, force 1.0, friction 5.0
• symbiosis: radius 0.06, beta 0.3, force 1.0, friction 4.0
• chaos: radius 0.07, beta 0.3, force 1.4, friction 6.0

Hmm, units: world height = 1.0. radius 0.055 = 5.5% of height. Sensible. force 1.0 → accel scale: f values are O(1) sums over maybe ~dozens of neighbors → accel up to 50? vel += fforcedt → dt0.016 → vel increments up to 0.8/frame?? That's too big. Need force scaling: multiply force by, say, 30 inside shader? Let me think: typical particle-life impls: force factor ~ 0.1-0.3 with dt=1 per frame (they integrate per frame, not seconds). I'll do: vel += f * (uForce * k) * dt with k chosen so typical speed looks right. Let me estimate: neighbors within radius on torus with 4096 particles: density = 4096 / area; area = aspect1 ≈ 1.7; density ≈ 2400 per unit². Disk area π0.055² ≈ 0.0095 → ~23 neighbors. Sum g each O(0.5) → f O(10). To reach speed ~0.05 world/s over ~1s: need accel ≈ 0.05friction? At equilibrium with damping: v_eq = accel/frictionRate = (fkforce)/friction... With friction rate 4/s: v_eq = 10k/4 = 2.5k. For v_eq ≈ 0.05 → k ≈ 0.02. So shader multiplier k=0.02 with uForce=1.0. I'll fold k into shader: vel += f * uForce * 0.02 * uDt? Hmm 0.02dt where dt in seconds — with dt=1/60, increments are tiny; damping exp(-4dt)≈0.935 per frame. v_eq: increment per frame at equilibrium = damping loss: fkdt = v*(1-exp(-frdt)) ≈ vfrdt → v = fk/fr = 100.02/4 = 0.05 ✓. Speed cap vmax = radius1.5/s ≈ 0.08. Good.

Actually, hmm, dt in seconds: 0.016. fkdt = 100.020.016 = 0.0033 per frame — fine.

Slider ranges: force 0..3 (default 1), radius 0.02..0.12, beta 0.05..0.6, friction 0.5..10, trails 0.80..0.995, species 2..8.

Substeps: 2 per frame with dt/2 each.

Pointer sign: default attract; shift or right-click repel. pointermove updates uPointer (world coords). pointerdown sets active; pointerup clears. Multi-touch: first pointer.

Screen→world: ndc = (x/w2-1, -(y/h2-1)); world = ((ndc.x*0.5+0.5)worldW, (ndc.y0.5+0.5)*worldH).

Stats readback: renderer.readRenderTargetPixels(stateRT, 0,0,tx,ty, buf) where buf = Float32Array(txty4) — but stateRT texture is RGBA32F; readPixels RGBA/FLOAT allowed. But careful: cur may be a DataTexture on frame 1 only; after that always RT. Do readback only when cur is an RT (frame ≥1). Compute: meanSpeed per species, entropy on 24×14 grid. Also count "clustered"? skip.

Entropy display: H normalized 0..1.

Legend: dots colored per species + thin activity bar (width via transform scaleX) — updated from stats.

OK — also New Universe = randomize matrix (genesis-like) AND reseed positions; Reseed separate? Combine: New Universe button does both. Preset chips apply matrix+params+reseed? Just matrix+params, keep positions (nicer to watch melt into new behavior); add small "RESEED" button too. Good.

Snapshot filename: microcosm-YYYYMMDD-HHMMSS.png.

Adaptive quality: measure EMA fps over 3s windows; if <45 → step down (high→med→low), rebuild sim textures + geometry; if >58 for 10s and below max → step up. Start at ?q param or 'high' default... For llvmpipe test, q=low. Auto-adapt handles weak machines.

Also handle context: antialias false (we do post), alpha false, powerPreference high-performance.

Bloom params: strength 0.85, radius 0.55, threshold 0.55.

Vignette handled in grade pass; keep #vig DOM overlay too? The grade vignette suffices; keep DOM one subtle as well — 057 used DOM. I'll skip DOM vig, do in shader.

Title: "MICROCOSM" subtitle "particle life · gpu ecology · emergent cells".

Demo card description for index (short but juicy).

Index.html insertion: find line 100 <a class="demo-card" href="./057-basin/index.html"> and insert before it. Need to see exact card markup to replicate. Let me view lines 90-115 of index.html.

Structure is clear. Now I'll write the demo. This is a big file — I'll write it in full. Let me compose it carefully.

I'll write /space/demos/058-microcosm/index.html now. Since it's large, I might write it via the read_write_file tool in one go. The tool should handle large content. Let me draft the complete file mentally then write.

Important details to get right:

1. Import map with three@0.160.0 (or 0.165?) — prior demos presumably use a pinned version; use 0.160.0 like many. Let me check what 057 uses to stay consistent — I saw only head 60 lines; the import map is further down. Let me just check quickly... I'll grep for the importmap in 057.

Actually let me quickly grep.

Good — three@0.160.0 with import map. Now I'll write the complete demo file. This will be a large write (~1000+ lines). Let me compose it fully and carefully.

Plan the file layout:

Let me write the JS modules carefully:

Constants:

Palettes:

These are used as emissive colors directly (HDR-ish gain applied).

Species names (for tooltip): ['RED','AMBER','LIME','TEAL','AZURE','VIOLET','MAGENTA','PEARL'] — palette independent generic names: use letters? Use names above.

Renderer init:

Camera: const camera = new THREE.OrthographicCamera(-1,1,1,-1,0,1);

Scenes:

• simScene: quad with update material.
• fadeScene: quad with fade material.
• pointScene: Points object (drawn into trail target after fade, with autoClear false).
• mainScene: composite quad.

Pass helper: const passCam = camera;

Quality tiers:

State:

DataTexture creation:

RT creation:

Trail RTs sized = renderer drawing buffer size (width*dpr). On resize, recreate. FloatType for HDR trails.

Materials:

Update material uniforms:

Fragment (GLSL3 via material.glslVersion = THREE.GLSL3). As discussed, three injects pc_fragColor & defines gl_FragColor. Actually wait — does three do that for ShaderMaterial? Let me recall WebGLProgram.js: for fragment shaders when customDefines... The relevant code:

Hmm, actually the automatic pc_fragColor injection happens when isWebGL2 && glslVersion === GLSL3? Let me recall... In three r160 WebGLProgram:

Hmm, I remember the magic: for RawShaderMaterial nothing is prepended. For ShaderMaterial with GLSL3, three prepends '#version 300 es' and built-ins, and for fragment shader it does add:

Yes — this is in WebGLProgram.js: in the fragment prefix, when parameters.glslVersion === GLSL3, includes that. I'm fairly confident (it's how all three's own materials work in WebGL2). So using gl_FragColor in a GLSL3 ShaderMaterial works, and I must not redeclare an out. Also texture(), texelFetch(), textureSize() available.

Alternatively, to be extra safe, I could write shaders in GLSL1 style (texture2D) and let three compile as GLSL3 automatically (it converts? no—). three in WebGL2 compiles all shaders as GLSL3 with compatibility defines: #define texture2D texture etc. So even plain ShaderMaterial (no glslVersion) gets compiled with '#version 300 es' and #define texture2D texture, plus pc_fragColor. So I can write old-style texture2D and still use texelFetch? texelFetch exists in 300 es; textureSize too. If I don't set glslVersion, three still compiles as 300 es in WebGL2 with defines for texture2D. texelFetch would be available since version is 300 es. Yes — three always compiles GLSL3 under WebGL2 for ShaderMaterial (with backwards-compat defines). Good: I'll just write modern syntax (texture(), texelFetch, textureSize, gl_FragColor) WITHOUT setting glslVersion — three prepends 300 es automatically in WebGL2. texelFetch is fine.

Loop with dynamic N: int N = uTexSize.x*uTexSize.y; — pass as uniform ivec2 or compute from textureSize(uState,0). textureSize is fine.

Points vertex shader: uses texture(uState, position.xy) — vertex texture fetch, fine in WebGL2.

One catch: in the vertex shader of Points, attribute position is vec3; I store texcoord in position.xy. gl_PointSize = uSize (in pixels, scaled by DPR — set uSize = base * pixelRatio... gl_PointSize is in device pixels? It's in pixels of the drawing buffer. So uSize should be base * drawingBufferHeight / clientHeight... simpler: uSize = baseSize * pixelRatio where pixelRatio = renderer.getPixelRatio(). base ~3.5.)

Composite shader: includes hash/noise/fbm for background.

Grade shader:

Note ShaderPass uniforms convention: tDiffuse automatically set. My grade shader needs vUv — ShaderPass uses FullScreenQuad with its own... ShaderPass renders using the given shader; the quad has uv attribute; standard pattern works (examples do varying vec2 vUv; with gl_Position = projectionMatrix * modelViewMatrix * vec4(position,1)? FullScreenQuad uses OrthographicCamera(-1,1,1,-1,0,1) and PlaneGeometry(2,2). So vertex: gl_Position = vec4(position.xy, 0.0, 1.0); works.

Composer setup:

Simulation loop per frame:

Wait — pointer should apply on both substeps; fine.

Trail:

Hmm indices: after swap, trailIdx = index of tw. Let me define: cur = trailIdx; write to trailRTs[1-cur]; then trailIdx = 1-cur. Then composite uses trailRTs[trailIdx].texture.

Points material uniform uState.value = readTex (latest state).

Clear trail on reset: setRenderTarget each + renderer.clear? With autoClear true and rendering nothing... simplest: renderer.setRenderTarget(rt); renderer.setClearColor(black,1); renderer.clear(). Do for both.

Composite: mainScene quad uniform tTrail = trailRTs[trailIdx].texture.

Then composer.render().

Adaptive quality:

Rebuild on tier change: rebuildSimTextures() (new state DataTexture reseeded... or preserve by copying current readTex into new RT? Simply reseed random — acceptable; but jarring. Better: render a copy pass into the first new RT using a copy material sampling old readTex — but sizes differ; bilinear sample — state is data not image; bilinear would corrupt (interpolating between different particles!). So reseed random. Fine — also show toast? Keep simple: reseed.)

Actually to be less jarring: keep it simple, reseed.

Rebuild: dispose old RTs/geometry, tex = TIERS[tier].tex, N = tex*tex, readTex = makeDataTexture(), stateRTs = [makeRT(tex,tex), makeRT(tex,tex)], writeIdx=0, rebuild points geometry with texcoords.

DPR tier: renderer.setPixelRatio(base*tier.dpr); composer.setSize; recreate trail RTs at new buffer size; update uRes uniforms; bloomPass resolution setSize via composer.setSize? UnrealBloomPass handles setSize through composer. Trail RT size: use renderer.getDrawingBufferSize(new Vector2()).

Resize handler: update worldW/H, camera unchanged (quad), renderer.setSize, composer.setSize, trail RTs recreate, uRes updates, uWorldSize update. Since world changes, positions outside new bounds — wrap handles (mod). Points positions mod — fine.

UI wiring:

Sliders: force, radius, beta, friction, trails, species. On input: update P and uniforms; species change → update uniform + matrix UI highlight + legend.

Buttons:

• NEW UNIVERSE: randomize genesis matrix + reseed.
• RESEED: reseed positions only.
• Preset chips: GENESIS/CELLS/HUNTERS/SYMBIOSIS/CHAOS → apply matrix + params (set sliders) without reseed.
• PALETTE: cycle palettes.
• AUDIO: toggle.
• PAUSE: toggle (space).
• SNAP: snapshot.

Matrix UI: build 9×9 grid: header row/col with color chips; cells S active. Update on species change and matrix change. Interactions: click: v = clamp(round((v+0.2)5)/5, -1, 1); right-click: minus; tooltip shows "A → B: +0.40 — amber attracts teal"? Wait semantics: m[i8+j] = force ON species i FROM species j. Positive = i attracted to j. Tooltip: "{name_i} feels {value:+0.2f} toward {name_j}" plus descriptor attract/repel.

Stats: fps, mean speed, entropy, per-species activity bars.

Readback every 45 frames:

readTex after first frame is always stateRTs[...].texture. To read pixels, need the render target, not texture: keep readRT reference alongside (set when stepping: readRT = target). Frame 1 readTex is DataTexture — skip readback until readRT set.

Compute per-species speed sums, entropy on grid 24×14, mean speed.

HUD: update every 500ms via textContent.

Audio module — write compact but complete:

Chords (Hz base A2=110): use semitone ratios. chordSets = [[0,3,7,10],[5,8,12,15]...]. 3 oscillators detuned saws: each osc freq = base * ratio^semi. Simpler: one osc per chord tone (3 oscs), update freqs per chord.

Pluck: osc triangle + gain envelope → delay feedback → master. Pentatonic: [0,2,4,7,9] + octaves.

New-universe whoosh: noise buffer → bandpass sweep down.

Snapshot:

Keyboard: space/N/R/A/P/Q/1..5.

Touch: pointer events on canvas; sliders native.

Help text: "drag: attract · shift/right-drag: repel · space: pause · n: new universe · r: reseed · 1–5: presets · a: audio · p: snapshot".

Edge: prevent context menu on canvas (for right-drag repel).

Pointer mapping:

Now the matrix default: start with GENESIS preset applied.

Params object P: {force:1.0, radius:0.055, beta:0.30, friction:4.0, trail:0.93, species:6}.

Presets with param sets as decided.

mat stored as regular Array(64) for easy UI editing; uniform value = mat (three accepts plain arrays for float arrays — uniform float uMat[64] → setValueV1fArray expects flat array — yes plain Array works).

Colors uniform: array of THREE.Color (or Vector3): uniform vec3 uColors[8] with value = array of THREE.Vector3/Color — supported.

Now, one more consideration — the update shader loop over N with two substeps: for 4096 particles, 4096 iterations × 4096 pixels... wait no: fragment shader runs per particle (4096 invocations), each loops 4096 → 16.7M total. OK.

ALU: each iteration does texelFetch + ~15 flops. Fine for GPU.

llvmpipe: 1024 particles (low tier) → 1M iterations per substep — llvmpipe will run maybe 2-5 fps at small window. Test at 800×600 window: acceptable.

Let me also make sure the sim is deterministic enough to show structure in ~5-10 seconds of test time: at 3 fps × 2 substeps × dt... dt clamped to 1/30 → sim advances 0.066s per frame max → 10s wall = 30 frames = 2s sim — barely enough for pattern formation. For the test, I'll add a ?turbo=1 param that runs more substeps (e.g., 8) so structure forms fast, and/or I can just verify colors/clusters statistically. Actually simpler: test waits longer and checks that pixel colors show ≥3 distinct hues and variance above threshold. Even at t=0 random init, all 6 species present → colorful. To verify dynamics, compare two screenshots 5s apart — they must differ substantially (proves sim running + trails). Good enough. Plus expose window.__micro debug handle with meanSpeed etc. for the test to read.

Actually even better for the test: expose window.__micro = { getStats: () => ({fps, meanSpeed, entropy, frame}) }. Test asserts frame advances and meanSpeed > threshold (sim active), and console error count 0.

Let me also handle ?q=low + ?nofx (disable bloom for test)? Bloom on llvmpipe is slow but works; keep bloom, test at low res window 640×480.

Alright — also the Entropy HUD label: "DIVERSITY" maybe. Fine.

Now — write it all. I'll aim for clean, commented code. Let me write the file now.

One more UI idea: "ACTIVITY" drives audio filter; species activity bars in legend.

Also document.title = "Microcosm — Particle Life Soup".

Let me write the HTML/CSS first (mentally), then the script. I'll write the whole thing in one big write call. Given its size (~40KB), the write tool should handle it; if too big, split into two writes (append via shell heredoc as fallback).

Let me carefully write out the entire file content.

Regarding fbm noise functions in composite shader:

Dust motes in background: sparkle: float m = step(0.9985, hash21(floor(p*140.) + floor(uTime*vec2? ...))) — twinkle:

OK. Writing now. Also remember pointer repel on right-drag: listen contextmenu preventDefault; pointerdown button===2 → sign=-1.

Slider for trails: 0.80–0.995 log-ish linear fine.

Species slider: 2–8 step 1.

Presets apply: set sliders positions too (update DOM inputs + value labels).

Value labels: each slider row shows current value.

OK, code time. I need to be careful about the total length. Let me write it.

Also: matrix grid cell hover — highlight cross: on mouseenter cell (i,j): add .hl to row i cells and col j cells. Implement via JS loops.

Tooltip content: e.g. "TEAL feels about AZURE: +0.60 (attracted)".

Cell text: value to 1 decimal? Show symbol: '++','+','·','−','−−'? Show numeric tiny (0.6). I'll show value with one decimal, color-coded background. Font-size 8px.

Legend with activity bars: div row: dot + name + bar(div with inner width%).

Stats panel: FPS / PARTICLES / SPEED / ENTROPY / TIER.

Now writing the full file.

Actually one more check — UnrealBloomPass import in r160: 'three/addons/postprocessing/UnrealBloomPass.js' ✓. It requires LuminosityHighPassShader internally — handled by addons.

RenderPass with ortho camera & quad scene ✓.

ShaderPass custom: needs uniforms, vertexShader, fragmentShader; ShaderPass clones uniforms via UniformsUtils.clone — passing object with texture in uniforms OK.

EffectComposer sizes: composer.setSize(w,h) on resize ✓ and setPixelRatio? EffectComposer has setPixelRatio — call composer.setPixelRatio(renderer.getPixelRatio()) then setSize. ✓

Now the write. I'll produce the file.

After writing: quick static checks:

• node --check on extracted module script (ES module with bare imports 'three' — node --check only parses, bare imports fine syntactically; use --input-type=module).
• grep balance of backticks/braces roughly.

Then install firefox + puppeteer-core, write test script, run, screenshot, iterate.

Time to write. Given size, I'll write in one go with the write tool (it supports large content). If it fails, fallback to heredoc in chunks.

Let me draft the complete code carefully — especially the GLSL and JS logic — before committing it to the write call.

Full shader strings:

UPDATE_FRAG:

Hmm: vmax = radius*1.6 per second — radius 0.055 → vmax 0.088 world/s. Crossing the world in ~20s. Reasonable for visible motion. Bump to 2.0 maybe. OK.

Wait, one thing: vel += force * (uForce*0.02) * uDt; with force magnitude ~ sum of ~20 neighbors × g(≤1) ≈ up to 20. → accel = 20*0.02 = 0.4 /s². v_eq = 0.4/friction(4) = 0.1 world/s — comparable to vmax 0.088 → lively but capped. Good.

Continue: if (j == idx) continue; — j==idx is the particle itself; skip.

uMat[sp*8+osp] — sp is int, 8 constant — fine.

POINTS_VERT:

position.z stores particle index (float). Good — geometry position attr = (u, v, index).

POINTS_FRAG:

Additive blending.

FADE_FRAG:

COMPOSITE_FRAG:

GRADE_FRAG as designed above.

Vertex shader shared (quad):

Now JS structure (single module script). I'll organize with section comments. Estimate ~700 lines JS. Let me now write everything.

I also want a small "toast" element to announce preset names / quality changes — nice UX touch: div#toast center-top, fades.

Let me finalize preset definitions:

Seeded randomness: mulberry32 with Date.now() seed — fine.

Write it all now. Also add <meta name="description">.

For robustness, wrap init in try/catch → show fallback with error message.

I must double check renderer.readRenderTargetPixels(readRT, ...) signature: (renderTarget, x, y, width, height, buffer). ✓ RGBA32F → Float32Array works when EXT_color_buffer_float present.

statBuf = new Float32Array(N*4) per tier.

For entropy grid 24×14 over world (worldW×worldH, aspect varies): fine.

Per-species activity: mean speed per species → bars normalized by vmax.

Now — writing the file. After that, validation.

Also note: DON'T forget to add depthWrite:false, depthTest:false on materials, blending: THREE.AdditiveBlending for points. Fade/composite materials NoBlending.

One risk: texture(uState, position.xy) in vertex shader with nearest filter, FloatType — OK.

Another: gl_PointSize maximum — llvmpipe supports up to 2048? Fine.

Points frustumCulled = false (positions are texcoords in [0,1], actual visual pos computed in shader).

Also pointScene.matrixAutoUpdate irrelevant.

Trail RT sizes: getDrawingBufferSize → trailRT = makeRT(size.x, size.y) — could be big (e.g., 2560×1440 at dpr2 → float RGBA = 16 bytes/px ×3.7M px = 59MB ×2 = 118MB). Hmm heavy but OK on desktop. Tier dpr reduces. Maybe cap trail buffer at 1920×1080? Cap drawing buffer size: size.multiplyScalar(Math.min(1, 19201080/(xy))?... simpler: clamp trail buffer max dimension: scale = Math.min(1, 1600/Math.max(x,y)); apply. I'll add that.

uTexel uniform = 1/trailSize.

OK writing now for real. The content is long; I'll do a single write call.

*********************************************************************************************************************************************************ck.

Syntax OK. Now set up the headless browser test environment. Following the previous run's approach:

1. Install Firefox + Mesa via apk.
2. npm install puppeteer-core + pngjs in /tmp.
3. Serve /space/demos over a local HTTP server (python3 -m http.server or node).
4. Run a test script: launch Firefox headless with WebGL software rendering prefs, load ?q=low, collect console errors, wait, screenshot, check pixel stats via pngjs, interact (click canvas, click New Universe), screenshot again, verify frames advance and colors present.

Let me install Firefox in the background while I prepare. apk add firefox — big download (~100MB+). Do it now.

The apk log write to /tmp/apk.log failed with permission denied — odd. Actually the error "Unable to open log: Permission denied" is apk's own log file (/var/log/apk.log?). Wait — "apk exit: 99" and the ERROR line went to stdout. apk couldn't open its log — probably /var/log/apk.log. Let me use apk add --no-cache --no-logfile? There is no such flag... Actually apk has --logfile option? Or run with -q? The issue is apk tries to open /var/log/apk.log. Maybe /var/log isn't writable. Let me check and just redirect: use apk add ... 2>&1 | tail and if log permission is the problem, create the dir or touch the file. Let me check whoami and /var/log permissions.

Running as agent, no root. /var/log/apk.log owned by root — apk can't write its log. Options:

• sudo? Check if available.
• apk has --no-logfile? Hmm, newer apk versions (2.14+) don't have that flag. There IS an env or option: apk --logfile? Not sure.
• Previous run installed Firefox successfully — how? Maybe they used sudo or ran as root then. Or the log file didn't exist then / was writable. The log file is from Oct 24 (yesterday's run) — so yesterday apk worked as root? /var/log/apk.log exists with root ownership dated Oct 24 11:11 — that's when the previous run installed packages, likely as root.

Check sudo/doas availability. If not, maybe apk has flag to skip log. Let me check apk help for log options.

***********************************************************************************************************************ly.

Dependencies are in. Now write the test script:

1. Serve /space/demos via a static HTTP server (node built-in, no deps — write a tiny static server in the test script itself).
2. Launch Firefox headless via puppeteer-core (puppeteer-core supports Firefox with browser: 'firefox').
3. WebGL software rendering prefs: Firefox headless with Mesa — force webgl.force-enabled: true, gfx.webrender.software: true, disable GPU process: webgl.disabled: false, and MOZ_HEADLESS env. Previous run used "Mesa surfaceless EGL support": env LIBGL_ALWAYS_SOFTWARE=1, MOZ_HEADLESS=1, maybe EGL_PLATFORM=surfaceless.
4. Load http://127.0.0.1:PORT/058-microcosm/?q=low
5. Collect console messages + pageerrors.
6. Wait ~8s, read window.__micro.frame/stats, screenshot to PNG.
7. Interact: click canvas center (pointer attract), click "New Universe" button, wait, screenshot again.
8. Analyze PNGs with pngjs: mean luminance, colorfulness (stddev of hue-ish), distinct colors. Compare frame1 vs frame2 difference (dynamics).
9. Report.

puppeteer-core Firefox support: puppeteer.launch({ browser: 'firefox', executablePath: '/usr/bin/firefox', headless: true, extraPrefsFirefox: {...} }). Newer puppeteer versions use WebDriver BiDi for Firefox by default. Screenshot works. prefs: extraPrefsFirefox requires... in newer puppeteer, use extraPrefsFirefox option. Let me just try.

Firefox prefs for software WebGL:

• 'webgl.force-enabled': true
• 'webgl.software-rendering': true? Actually pref webgl.forbid-software set false; modern Firefox: webgl.force-enabled=true, gfx.webrender.software=true, webgl.out-of-process=false? Let me set:
  • webgl.force-enabled: true
  • gfx.webrender.software: true
  • webgl.out-of-process: false
  • layers.acceleration.disabled: true? maybe not needed.
  • media autoplay: media.autoplay.default=0 to allow audio (not needed since audio off). Env: LIBGL_ALWAYS_SOFTWARE=1, MOZ_HEADLESS=1, EGL_PLATFORM=surfaceless? and GALLIUM_DRIVER=llvmpipe.

The previous run validated this exact combo works, so it should work here.

Also: my demo uses import maps + ES modules from unpkg — needs network access. Does this sandbox have internet? npm install worked, so yes.

Static server: write minimal node http server serving files from /space/demos with correct content types.

Note: window.__micro — BiDi page.evaluate works.

Also set viewport 800×600 to keep llvmpipe fast. Use ?q=low to force low tier and prevent auto-quality switching (my autoQuality won't upgrade when ?q present, but CAN still downgrade below low? order.indexOf('low')=0, downgrade requires i>0 → no downgrade from low. Good, pinned).

One concern in my code: applyDPR() calls onResize(true) which calls renderer.setSize etc. and skipTrail=true... but rebuildTrails never gets called on boot then! Let me trace boot:

1. rebuildSim() — state textures.
2. applyDPR() → renderer.setPixelRatio, composer.setPixelRatio, onResize(true) — sets sizes/uniforms, skipTrail → trails NOT rebuilt. trailRTs = [] at this point!
3. Then tick(): drawTrails() → trailRTs[trailIdx^1] = trailRTs[1] = undefined → crash!

Bug! In onResize, when skipTrail=true, trailRTs never built. I call applyDPR() at boot before any rebuildTrails. Need rebuildTrails() after. Fix: in boot, call applyDPR() then rebuildTrails(). Or make onResize always rebuild trails when trailRTs empty. Let me fix in the file: after applyDPR(); add rebuildTrails();

Also check: rebuildSim() is called BEFORE applyDPR — uses tex from tierName — fine.

Another check — drawTrails runs even when paused? No, inside if(!paused). But composite reads trailRTs[trailIdx].texture — after boot fix, trailRTs exist (cleared). Good.

Another possible issue: In stepSim, when readTex is a DataTexture (frame 1), updateMat.uniforms.uState.value = readTex (DataTexture) — fine, it's a texture.

rebuildSim disposes readTex if isDataTexture — on boot readTex is null → guard readTex && ok. I wrote if (readTex && readTex.isDataTexture) readTex.dispose(); — yes.

In doReseed — same guard yes.

autoQuality downgrade calls rebuildSim which reseeds — fine. But note: applyDPR() → onResize(true) skips trail rebuild → then rebuildSim() → trails stay (fine, existing). OK.

But wait — applyDPR calls onResize(true) which calls renderer.setSize(innerWidth, innerHeight) — idempotent, fine — but does NOT rebuild trails when DPR changed → trail buffer sized for old DPR. Mismatch only affects fade texel scale slightly; composite samples tTrail with vUv — resolution-independent. Acceptable. Actually on tier change, applyDPR changes pixelRatio, so drawing buffer size changes; trail buffer remains at old size — still works visually (stretched). Better: rebuildTrails after applyDPR in autoQuality? rebuildSim doesn't rebuild trails. Eh — let me make applyDPR do onResize(false) instead of (true), and in boot just call applyDPR() then it's all built (onResize(false) → rebuildTrails). But rebuildTrails needs renderer size set — yes setSize happens in onResize before rebuildTrails.

New boot order:

1. buildMatrixUI, buildLegend
2. rebuildSim()
3. applyDPR() → onResize(false) → sets sizes + rebuildTrails ✓
4. syncSliders, syncUniforms, applyPreset(GENESIS, false)
5. tick()

And applyPreset(GENESIS, false) — no reseed — fine.

But autoQuality calls applyDPR() which with (false) rebuilds trails too — good, and rebuildSim after. Order in autoQuality: applyDPR(); rebuildSim(); — trails rebuilt with new DPR ✓.

One more: onResize references gradePass.uniforms.uRes — gradePass defined before onResize is called (boot calls after definitions) ✓. But addEventListener('resize', ...) registered before composer/gradePass definitions? Order in file: composer created (line ~after rebuildTrails def), then applyDPR def, then onResize def + listener, then UI... boot at bottom. All defs before boot calls. ✓

Wait, there's another subtle issue: onResize is defined AFTER applyDPR which references it — function declarations hoist ✓.

Another check: slider input for species: parseFloat('6') → 6 ✓; syncUniforms sets uSpecies float ✓. refreshMatrixUI + buildLegend on species change ✓. Legend bars update loop k<P.species ✓.

Matrix cell click handler bumpCell — shows tip again after update ✓. AudioSys.blip guards !this.ctx ✓.

Potential three.js r160 gotcha: new ShaderPass({uniforms, vertexShader, fragmentShader}) — ShaderPass constructor accepts a shader object ✓; it clones uniforms with UniformsUtils.clone ✓ (Vector2 cloned fine).

UnrealBloomPass with NoToneMapping — fine.

Another gotcha: renderer.readRenderTargetPixels with FloatType RT — needs readPixels type FLOAT support — with EXT_color_buffer_float, Firefox allows RGBA/FLOAT readPixels. Chrome too. If it fails, try/catch sets statOK=false — stats stay 0 but demo continues. Good.

Edge: stats.entropy initial 0 → HUD shows 0% until first readback (frame 0 → frame%45===0 at frame 0? frame starts 0, tick: if(!paused){...frame++}; then if (frame % 45 === 0) readStats(); — frame=1 after first tick → readback at frame 45. But readRT null until first stepSim — readStats guards !readRT ✓.

window.__micro.stats — fine.

GLSL check — UPDATE_FRAG: uniform float uDt, uForce, ... — multiple uniforms in one declaration statement — valid GLSL ✓. uMat[sp * 8 + osp] — sp, osp ints; dynamic indexing into uniform array — allowed in GLSL3 (and even GLSL1 for uniforms? In ES 2.0, indexing uniform arrays with non-constant is allowed only in vertex shader; fragment needs constant-index-expression for sampler arrays only — for float arrays, dynamic indexing IS allowed in ES 2.0? Hmm: In GLSL ES 1.00, arrays can be indexed with constant-index-expressions in fragment shaders, EXCEPT uniforms which can be indexed by any integral constant-index-expression... Actually the rule: in ES 2.0 fragment shaders, indexing of uniform arrays with a non-constant expression is allowed only for... Let me recall precisely: GLSL ES 1.00 spec section 10.30? The restriction applies to sampler arrays (must be constant index). For non-sampler uniforms, dynamic indexing is supported in ES 2.0? Actually I believe in ES 2.0, indexing into non-sampler uniform arrays with dynamically uniform or even dynamic values works on most implementations and is legal... The spec says: "Indexing of arrays of samplers by constant-index-expressions is supported" and for other arrays: subscript can be any expression? Hmm. In ES 3.0 it's definitely allowed for non-sampler arrays. We compile as 300 es (three does under WebGL2) → dynamic indexing of float uniform array is legal. ✓

int(mod(float(idx), uSpecies)) ✓. continue in for loop ✓ GLSL.

gl_FragCoord used ✓.

POINTS_VERT: mod(position.z, uSpecies) — position.z up to 4095, float exact ✓.

GRADE: mod(uTime,10.0) fine.

One more: pointsMat.uniforms.uColors.value = paletteColors() on palette cycle — array of THREE.Color → uniform vec3 array ✓.

Fade shader blur weights: 0.44 + 4×0.14 = 1.0 ✓ then decay.

Also confirm: simScene quad uses PlaneGeometry(2,2) — has uv attribute ✓ (0..1 across plane). vUv from uv ✓. gl_Position from position.xy directly — PlaneGeometry(2,2) spans -1..1 ✓.

DataTexture default flipY=false, unpackAlignment — for float data, alignment 4 default? Data RGBA float: row width tex44 bytes — divisible by 4 ✓.

Trail RT FloatType — fade reads and writes float ✓. Points render into float RT with additive blending — float blending supported with EXT_color_buffer_float? Blending of 32F render targets requires EXT_float_blend on some impls! EXT_color_buffer_float makes them renderable; blending 32F needs EXT_float_blend extension (separate). On Firefox/Mesa and Chrome/ANGLE it's widely available, but to be safe I should request it: gl.getExtension('EXT_float_blend'). If unavailable, could fall back to HalfFloatType for trail RTs. Let me add: request EXT_float_blend; if missing, make trail RTs HalfFloatType. Simple: add a global trailType chosen at boot. makeRT is used for both state and trails — state MUST be FloatType (precision) and is never blended ✓. Trails can be half float. I'll parametrize makeRT(w,h,type).

Also check EXT_color_buffer_half_float implicit in WebGL2? Half-float renderable needs EXT_color_buffer_float too (it covers both 32F and 16F). ✓ EXT_color_buffer_float covers RGBA16F renderability. Blending 16F is core-ish? In WebGL2, blending float16 is allowed when EXT_color_buffer_float present; 32F blending needs EXT_float_blend. So: trails → just use HalfFloatType always! HDR range ±65504 — plenty, less memory, blending-safe.

Let me patch:

1. makeRT(w, h, type) — state uses FloatType, trails use HalfFloatType.
2. Boot: remove rebuildTrails problem — change applyDPR to call onResize(false), and boot order stays: rebuildSim(); applyDPR(); (onResize(false) → rebuildTrails ✓). But onResize references trailRTs in rebuildTrails — fine. Wait: applyDPR is ALSO called in autoQuality before rebuildSim — order fine. But careful: onResize(false) → rebuildTrails() disposes old trailRTs — empty array first time ✓.
3. Also request EXT_float_blend not needed anymore.

One more boot check: rebuildSim() is called before applyDPR → buildPoints uses tex ✓; statBuf set ✓.

And in onResize, pointsMat.uniforms.uSize.value = 4.2 * renderer.getPixelRatio(); ✓.

Also in rebuildTrails: renderer.setClearColor(0x000000,1) — changes global clear color — subsequent setRenderTarget(target) for sim writes — sim renders fullscreen quad with autoClear true → renderer.clear() before render with black — fine (whole target overwritten anyway).

Now patch the file.

Patch 1: makeRT signature:

and stateRTs = [makeRT(tex,tex,THREE.FloatType), ...]; trails: makeRT(w,h,THREE.HalfFloatType).

Patch 2: applyDPR: onResize(false). And in boot, applyDPR(); already there — with comment update. But note boot also calls rebuildSim() BEFORE applyDPR — good.

Also remove onResize(true) special case? Keep the flag but pass false. Actually simpler: keep signature, change applyDPR body to onResize(false).

Let me apply the patches.

Now, there's one more subtle issue: readStats does renderer.readRenderTargetPixels(readRT, 0, 0, tex, tex, statBuf) — readRT is FloatType RGBA32F — readPixels RGBA/FLOAT — OK.

But careful: readStats runs between frames while a render target may be bound? No — at end of tick, setRenderTarget(null) done in drawTrails and composer.render ends with null. OK.

Another consideration: onResize gets called via addEventListener('resize') and via applyDPR — at boot, order: rebuildSim() → applyDPR() → onResize(false) → rebuildTrails ✓. syncSliders/syncUniforms → applyPreset(GENESIS,false) → setMatrix (refreshMatrixUI) + Object.assign(P, params) + syncSliders + syncUniforms ✓.

Now write the test script. Node script at /tmp/ptest/test.mjs:

• tiny static file server on 127.0.0.1:8123 serving /space/demos.
• puppeteer-core launch firefox:

• page = await browser.newPage(); await page.setViewport({width: 800, height: 600});
• capture console: page.on('console'), page.on('pageerror').
• goto http://127.0.0.1:8123/058-microcosm/?q=low, waitUntil 'networkidle2' timeout 120000 (unpkg downloads).
• wait for window.__micro: page.waitForFunction('window.__micro !== undefined', {timeout: 60000}).
• sleep 10s (sim frames accumulate; llvmpipe slow).
• evaluate __micro.frame, stats.
• screenshot /tmp/shot1.png.
• click canvas center: page.mouse.click(400,300) → pointer attract; hold? Just click + move.
• click #bNew (New Universe) — wait 3s.
• screenshot /tmp/shot2.png.
• evaluate frame again → frames advanced.
• analyze PNGs with pngjs: mean luminance, %non-dark pixels, distinct hue count, diff between shots.

Console "errors" collection: filter severity error. Note Firefox may log warnings (e.g., downloadable font). Only fail on pageerror / console 'error'.

BiDi console events: puppeteer 'console' event works with BiDi. pageerror too.

Timeouts generous. Total run maybe 60-90s.

Serve content types: .html text/html, .js/.mjs text/javascript, .png image/png.

Let me write the test script now.

window.__micro never became defined — the module script either failed early or didn't load. Console errors were collected but not printed because the crash happened before printing. Let me modify the test to print errors on failure, or better run a quick diagnostic: load the page, wait 20s, dump console messages and check window.__micro + whether WebGL2 is available.

Possible causes:

1. unpkg.com not reachable from Firefox? npm worked, so net is up.
2. The module threw before reaching window.__micro assignment (which is at the very end of the module). E.g., the fallback path: if !WebGL2 → we throw new Error → module dies → __micro never set. That would happen if WebGL2 isn't available in Firefox/llvmpipe. But the previous run validated WebGL on this exact setup (Firefox + Mesa llvmpipe). WebGL2 should be there.
3. A JS error early (e.g., PRESETS[+e.key-1] fine...).
4. import maps + module from unpkg slow.

Let me write a diagnostic script that prints all console messages live and checks status after a delay.

Firefox can't create a WebGL context: "tryNativeGL → Exhausted GL driver options". The fallback displayed correctly (good — fallback works!). Firefox headless needs software GL. The previous run got it working with "Firefox with Mesa surfaceless EGL support". Firefox tries native GL first; with EGL_PLATFORM=surfaceless and libEGL from mesa, it should work. The issue might be:

1. gfx.webrender.software: true set, but WebGL context creation uses EGL. Setting env EGL_PLATFORM=surfaceless may help.
2. Firefox sandbox in headless mode blocking GPU process — maybe need MOZ_DISABLE_CONTENT_SANDBOX or run with --no-sandbox? WebGL runs in the GPU process (or main when webgl.out-of-process=false... actually pref webgl.out-of-process: false should force in-process GL).
3. Maybe mesa-dri-gallium provides swrast but Firefox's EGL needs LIBGL_ALWAYS_SOFTWARE=1 + GALLIUM_DRIVER=llvmpipe — I set those env vars. But "tryNativeGL" then "Exhausted GL driver options" suggests EGL didn't even get tried — on Linux Firefox uses EGL by default for WebGL now.

Env vars to try:

• EGL_PLATFORM=surfaceless
• MOZ_GFX_OMTP_WORKAROUND? no.
• Firefox prefs: webgl.force-enabled=true didn't help since context creation happens natively.
• Maybe need pref gfx.offscreencanvas.enabled? no.

Let me check what the previous successful run did — the summary says: "installing Firefox with Mesa surfaceless EGL support" and "resolved by installing Firefox with Mesa surfaceless EGL support". So EGL_PLATFORM=surfaceless env is likely the missing piece.

Also possibly MOZ_HEADLESS=1 plus... let me try adding EGL_PLATFORM=surfaceless and also DISPLAY= unset (no X). Firefox headless doesn't need X.

Also add pref 'webgl.disable-fail-if-major-performance-caveat': true? Not needed with force-enabled.

Let me also try MOZ_DISABLE_CONTENT_SANDBOX=1 and MOZ_DISABLE_GMP_SANDBOX=1 — sandbox can block /dev/dri access, but llvmpipe doesn't need /dev/dri... EGL surfaceless with llvmpipe should not need device nodes.

Also ensure mesa-egl installed ✓ and mesa-gl ✓. Where's libEGL? /usr/lib/libEGL.so.1 from mesa-egl? mesa-egl package provides libEGL. And DRI drivers in /usr/lib/dri (mesa-dri-gallium) including swrast_dri.so? On Alpine, llvmpipe/swrast is in mesa-dri-gallium ✓.

Quick test: run diag with EGL_PLATFORM=surfaceless added.

swrast_dri.so exists. Good. So the driver is available; Firefox must be failing earlier. Let me test Mesa EGL directly with a small C or python probe... quicker: use eglinfo? Not installed.

Alternative approach used by the PREVIOUS run: it worked. What did they do differently? "Configured a headless automated test environment using Puppeteer and Firefox with Mesa/llvmpipe software WebGL rendering." Perhaps they launched Firefox with MOZ_HEADLESS=1 and prefs including webgl.software-rendering: true? Is there such a pref? There is webgl.software-rendering in newer Firefox (since ~127?) which forces software WebGL via SwiftShader-like (llvmpipe)? Actually Firefox Nightly added webgl.software-rendering pref using lavapipe? Hmm, Firefox doesn't bundle SwiftShader.

Another thought: maybe the issue is that with MOZ_HEADLESS, Firefox disables GPU process entirely and native GL context creation is blocked; setting gfx.headless.use-surfaceless? Not a real pref.

Let me look at actual Firefox gfx code knowledge:

• WebGL context creation on Linux: GfxInfo → GLContextProviderEGL — with MOZ_HEADLESS it still creates GLContextEGL with surfaceless. The log "tryNativeGL ()" then "Exhausted GL driver options" — in dom/canvas/WebGLContext.cpp: tryNativeGL then tryGLES? Hmm.

Maybe the problem: WebGL fails because Firefox determined GL is blocklisted due to GPU process failure earlier (during startup, before env applied?). Also "FEATURE_FAILURE_WEBGL_EXHAUSTED_DRIVERS" — search memory: this appears when WebGLContext::CreateAndInitGL exhausted: tryNativeGL, then... it's logged via GenerateWarning. The underlying GL context creation failed for real.

EGL surfaceless test outside Firefox would help isolate: is Mesa EGL+llvmpipe functional at all? Install mesa-demos? Alpine has mesa-demos package providing eglinfo/glinfo? Let me check quickly: apk search mesa-demos. glxinfo needs X; eglinfo can run headless with surfaceless.

Actually — simpler first test: does a plain C program with EGL work? Use node with a quick FFI? Too complex. Try apk add mesa-demos and run eglinfo -B with EGL_PLATFORM=surfaceless.

Alternatively, maybe simpler: run Firefox under Xvfb! xvfb provides a plain X server; GLX with llvmpipe works under Xvfb — classic approach. apk add xvfb (xorg-server-xvfb?). Alpine package: xvfb? There's xorg-server-xvfb? Hmm, on Alpine it's xvfb I think... let me check apk search.

With Xvfb: run Xvfb :99 &, env DISPLAY=:99, launch Firefox NON-headless (headless false but with MOZ_HEADLESS unset) — Firefox will create window on Xvfb; GLX via Mesa swrast works. This is the most reliable route. Puppeteer: headless: false, env DISPLAY=:99.

Let me try Xvfb approach. Need packages: xvfb (server), plus fonts (ttf-dejavu installed), maybe xterm not needed.

apk add xvfb — on Alpine the package is xvfb? I recall xvfb exists ("X virtual framebuffer"). There might be xorg-server-xvfb in newer Alpine. Let me search.

Progress threshold at 50% max time. I need to be efficient. Let me test eglinfo quickly and move forward with Xvfb if needed.

Plan:

1. Quick eglinfo test (fast).
2. If surfaceless works, then Firefox pref issue — try prefs webgl.software-rendering maybe.
3. Else go straight to Xvfb: apk add xvfb (check package name via apk search).

Let me batch: run eglinfo surfaceless + search xvfb package in one command.

Mesa surfaceless EGL + llvmpipe works perfectly (GL 4.5). So Firefox just isn't picking the surfaceless platform. No xvfb package found in Alpine 3.23 repos (xvfb search empty) — maybe xorg-server-xvfb? apk search returned nothing for "xvfb" — hmm. Let me search xorg.

But first — Firefox WebGL with headless: The proper modern way in Firefox ≥ 115-ish: pref webgl.software-rendering doesn't exist; the correct approach for headless software WebGL in Firefox is... Actually I recall: Firefox in headless mode CAN do WebGL via EGL surfaceless if pref gfx.webrender.software: true AND the env EGL_PLATFORM=surfaceless... we tried. Hmm, but did the env actually reach the right process? Puppeteer env applies to the main process; GPU/content processes inherit env ✓.

Wait — actually the error text has changed meaning: "tryNativeGL ()" — there may be more detail in Firefox stdout. Let me capture Firefox process stdout/stderr by adding dumpio... puppeteer.launch({dumpio:true}) pipes browser output.

Alternative quicker shot: pref webgl.forbid-software: false? Default is true maybe? Hmm — if Firefox's GfxInfo blocklists llvmpipe, context creation refuses. webgl.force-enabled should override. There's also webgl.disable-fail-if-major-performance-caveat.

Actually wait — maybe the REAL problem: MOZ_HEADLESS + content process creates WebGL via the GPU process normally; with webgl.out-of-process: false we forced in-process GL in the CONTENT process. Content process sandbox (even with MOZ_DISABLE_CONTENT_SANDBOX=1)... we disabled. Hmm.

Let me just capture dumpio to see Firefox's own log messages. Actually, faster plan: try Chromium instead? The previous run said Chromium failed due to missing SwiftShader in Alpine musl. But maybe I can install chromium via apk — Alpine has chromium package! The previous run said "Chromium WebGL context creation failed due to missing SwiftShader libraries in the Alpine environment" — maybe they used a Chromium binary from puppeteer (glibc-linked, won't run on musl anyway) rather than Alpine's chromium. Alpine's chromium package includes swiftshader ANGLE (libvk_swiftshader) — typically works with --use-gl=swiftshader / --use-angle=swiftshader. But that's what failed before...

Focus: Firefox + EGL. Let me try dumpio to read Firefox logs. Add MOZ_LOG=WebGL:5? There's MOZ_LOG "CanvasWebGL:5"? Let me do dumpio + grep for GL/EGL lines. Quick single run.

Still failing on about:blank with a raw webgl2 probe. So the demo code is fine — it's purely Firefox's WebGL init in this environment.

Interesting line: "RenderCompositorSWGL failed mapping default framebuffer, no dt" — headless compositing issue.

Options to make Firefox use EGL surfaceless for WebGL:

1. Pref gfx.x11-egl.force-enabled: true? That's for X11.
2. There's a Firefox env var MOZ_X11_EGL=1 for X11 EGL. For headless — hmm.
3. Maybe the problem is that in headless mode, GLContextProviderEGL picks EGL_PLATFORM_X11? There might be pref/env to force: Firefox GLContextProviderEGL.cpp: it uses GLLibraryEGL::Init which checks gfxPlatformGtk::IsHeadless()? Hmm.

I recall headless Firefox WebGL historically works out of the box with MOZ_HEADLESS=1 using osmesa-ish path? Not anymore.

Let me think about what the PREVIOUS run did exactly: "Transitioned browser automation from Chromium to Firefox with Mesa llvmpipe when Chromium encountered container-specific GPU/ANGLE initialization failures in the Alpine musl environment." — So they made Firefox work. The env there... They said "Firefox with Mesa surfaceless EGL support". Maybe they set BOTH EGL_PLATFORM=surfaceless AND ran with a profile setting webgl.out-of-process: false, plus importantly — maybe they set HOME to a writable dir, and used MOZ_DISABLE_CONTENT_SANDBOX... We did those.

Hmm, wait — maybe the actual missing piece: XDG_RUNTIME_DIR. eglinfo printed "error: XDG_RUNTIME_DIR is invalid or not set" for GBM platform — but surfaceless worked anyway. For Firefox though, maybe GBM/DRM attempt failure cascades. Try setting XDG_RUNTIME_DIR=/tmp/xdg (mkdir, chmod 700).

Also try MOZ_DBUS_REMOTE=0? dbus issues could crash GPU process.

Let me also check Firefox version: firefox --version.

Another angle: use the GPU process but let IT do EGL surfaceless: default (webgl.out-of-process true) — maybe in-process fails due to sandbox even with MOZ_DISABLE_CONTENT_SANDBOX... we set that env. But puppeteer launch args may add --safe-mode? No.

Let me try a matrix quickly via a script that tries combinations: A) XDG_RUNTIME_DIR set + out-of-process false + EGL_PLATFORM=surfaceless + MOZ_DISABLE_CONTENT_SANDBOX. B) Same but out-of-process default (remove pref). C) Add MOZ_X11_EGL? not without X.

Also firefox --version to know what we're dealing with. Firefox ≥ 128 ESR? Alpine 3.23 ships firefox 144+ probably.

Additional env: MOZ_GFX_OMTP_WORKAROUND? no.

Try also pref: gfx.webrender.software: true (have), layers.acceleration.disabled: true?

And maybe widget.headless.forbid-native-gl? Not a thing.

Hmm — actually! I remember: Firefox headless WebGL works with MOZ_HEADLESS=1 ONLY via the "Basic" compositor + software GL; the log "RenderCompositorSWGL failed mapping default framebuffer, no dt" is a known benign-ish headless message but indicates compositor fallback issues.

Let me just try the env combos — fast iteration with diag2 variants. I'll create a loop script testing several configs in one run, each: launch → probe webgl2 → close. Keep each launch ~10s.

All combos fail. Something more fundamental. Let me check firefox version and see if there's a known issue. Also try:

1. firefox --version
2. Maybe Firefox needs MOZ_WAYLAND? No.
3. Check if libGL being from mesa-gl vs libglvnd matters — Alpine mesa-gl might be libglvnd-based. Firefox loads "libGL.so.1" via dlopen for GLX (native GL) and "libEGL.so" for EGL. Both exist.
4. Maybe the GPU process crashes and webgl blocklist gets written into the profile; using fresh profile each launch — puppeteer creates temp profile ✓.

Key insight: "tryNativeGL ()" means it tried native GL (GLX) which failed, and then gave up WITHOUT trying EGL. In headless mode without X11, GLX can't work. Firefox's WebGL code tries EGL only when... gfx.webgl.egl.enabled? Hmm, I don't remember such pref. Wait — for WebGL on Linux, Firefox REQUIRES EGL since FF 96ish? The message "tryNativeGL" in newer Firefox actually means "try creating GL context via the default provider"...

Let me check firefox version first, and maybe grep the firefox binary/libxul for relevant prefs like "webgl.egl":

strings libxul.so | grep -i "webgl.*egl|gfx.*egl.*force" — could reveal pref names. libxul is huge (~150MB); strings may take a while but let's try with grep limited.

Also look for "EGL_PLATFORM" handling — Firefox GLContextProviderEGL reads env MOZ_EGL_PLATFORM? Not sure.

Alternative: try Xvfb route — need the package. apk search xvfb returned nothing. Try apk search xorg-server to find exact package name. In Alpine, the xvfb package is named xvfb in community repo... but community repo might not be enabled? apk search worked for other stuff (mesa-demos installed fine). Let me check /etc/apk/repositories and search again for xvfb/xorg.

Firefox 151.0.3. apk search failed due to cache warnings (need apk update first probably, or the agent user can't read cache — earlier apk add worked via sudo with --no-cache). Let me use sudo apk search won't work offline... Actually apk search xvfb needs the index; use sudo apk update quickly then search.

Also on Firefox 151: In recent Firefox (≈140+?), there's a new pref webgl.software-rendering — I genuinely recall Firefox adding a software WebGL mode using its bundled... no wait, that's Chrome. Hmm.

Actually for FF 151, I remember discussions: "Firefox headless WebGL broken" — the known working recipe is:

and it works on Ubuntu with mesa installed. On Alpine, mesa-gl installed... Maybe missing package: mesa-glapi? Or libxcb? Firefox GLX path needs libX11 even in headless? firefox package pulls X libs as deps ✓.

Hmm — what about mesa-gbm? EGL GBM platform needs libgbm (mesa-gbm package). eglinfo GBM failed ("XDG_RUNTIME_DIR invalid" — actually GBM usually needs /dev/dri). Surfaceless doesn't need gbm.

What exactly does Firefox 151 do for WebGL GL context creation headless? Let me look at it differently — run Firefox directly from CLI with a test page and MOZ_LOG to see the GL init logs:

MOZ_LOG="WebGL:5, gfx:5"? The module name for GL context is "GLContext"? Try MOZ_LOG="WebGL:5,GLContext:5,gl:5".

Let me run firefox CLI directly (not via puppeteer) with a data: URL... CLI: MOZ_HEADLESS=1 firefox --headless --screenshot /tmp/ff.png 'data:text/html,<canvas id=c></canvas><script>document.title=!!c.getContext("webgl2")</script>' — --screenshot doesn't run JS? It does render the page. Title wouldn't show in screenshot. Better: use the canvas to draw: if webgl2 exists, document.body.style.background='green' else 'red'; screenshot shows color. That works with --screenshot (waits for load + a delay?). --screenshot waits for page load; script runs synchronously during parse → bg set before screenshot ✓.

Write test HTML file to /tmp/glt.html with inline script drawing green/red body. Then: MOZ_HEADLESS=1 LIBGL_ALWAYS_SOFTWARE=1 ... firefox --headless --screenshot /tmp/ffshot.png --window-size=200,200 file:///tmp/glt.html Then analyze pixel color with pngjs... just check mean RGB via node one-liner.

But is this the best use of time? Alternative: give up on visual validation entirely? NO — validation is required by the task. Alternative 2: write a tiny EGL+GLES2 C program to compile my shaders? That validates shaders but not three.js behavior.

Better alternative: validate with node + headless-gl? gl npm package (headless-gl) — needs compilation, WebGL1 only — insufficient (we need WebGL2).

Another alternative: Chromium from Alpine repos — apk add chromium. Previous run says Chromium failed "due to missing SwiftShader" — but maybe with the right flags Alpine's chromium works: Alpine chromium ships ANGLE with swiftshader in /usr/lib/chromium/. Flags: --headless=new --no-sandbox --use-angle=swiftshader --enable-unsafe-swiftshader (newer Chrome requires --enable-unsafe-swiftshader for software WebGL!). The "missing SwiftShader" failure from the previous run might have been the OLD error; newer Chromium needs --enable-unsafe-swiftshader flag. That's worth a try! Chromium 131+: software WebGL fallback requires --enable-unsafe-swiftshader.

Let me try both in parallel-ish:

1. firefox CLI screenshot test with MOZ_LOG to understand (quick).
2. apk add chromium and try puppeteer-core with executablePath /usr/bin/chromium-browser (or /usr/bin/chromium), flags --no-sandbox --headless=new --enable-unsafe-swiftshader --use-angle=swiftshader --disable-gpu-sandbox.

Chromium route is promising. Puppeteer-core supports Chrome/CDP fully. Let me install chromium first (it's big ~300MB but apk is fast).

Also note for chromium: sandbox needs --no-sandbox since we're not root but user namespaces may work; add --disable-dev-shm-usage.

Do it.

Chromium installed with ANGLE libs (libEGL.so, libGLESv2.so, libvulkan.so.1 — this libvulkan is likely SwiftShader's Vulkan ICD "vk_swiftshader"?). Let me test with puppeteer-core: executablePath /usr/bin/chromium, args:

• --headless=new (or headless: true)
• --no-sandbox --disable-dev-shm-usage
• --use-angle=swiftshader / or --use-gl=angle + --use-angle=swiftshader
• --enable-unsafe-swiftshader

Test script diag4.mjs: launch chromium, probe webgl2 + RENDERER.

Now I understand Chromium's failure: ANGLE over Vulkan (SwiftShader Vulkan) fails — "Extension not supported: VK_KHR_surface / VK_KHR_xcb_surface". Chromium's SwANGLE needs VK_KHR_surface from SwiftShader's Vulkan ICD, which apparently isn't supported here (musl Alpine SwiftShader build?). The Vulkan loader (libvulkan.so.1 in chromium dir) is SwiftShader's. It lacks surface extensions → ANGLE Vulkan backend can't init.

Can I make ANGLE use its OpenGL backend instead of Vulkan? --use-angle=gl? Options: --use-angle=gl / gl-egl / gles-egl. With system Mesa EGL surfaceless! Chromium ANGLE with "gl" backend dlopens system libGL (mesa). That could work: --use-gl=angle --use-angle=gl-egl uses EGL with system EGL (mesa surfaceless? Chromium's ozone headless creates surfaceless EGL). Actually --use-angle=gl-egl: ANGLE's OpenGL-through-EGL backend, using system libEGL — Mesa's libEGL with EGL_PLATFORM... Chromium sets its own EGL_PLATFORM? With ozone headless, ANGLE uses EGL_PLATFORM_SURFACELESS? Hmm, ANGLE gl-egl backend uses the default display. Mesa eglGetDisplay(EGL_DEFAULT_DISPLAY) without X → fails? Mesa default display honors EGL_PLATFORM env var! Set EGL_PLATFORM=surfaceless → Mesa returns surfaceless display → llvmpipe.

So: --use-gl=angle --use-angle=gl-egl + env EGL_PLATFORM=surfaceless + LIBGL_ALWAYS_SOFTWARE=1.

Or --use-angle=gl (GLX) — needs X. gl-egl is the way.

Also try --use-angle=gles-egl.

Let me test these two flag combos.Chromium's SwiftShader-Vulkan lacks VK_KHR_surface on musl — dead end for SwANGLE. But ANGLE's gl-egl backend can ride on Mesa's system libEGL with surfaceless platform (which works!). Trying --use-angle=gl-egl with EGL_PLATFORM=surfaceless:

Still failing. Chromium GPU process probably still defaults to SwANGLE/Vulkan or fails elsewhere. I need the log again for the gl-egl attempt. But maybe faster: check what GPU process does. Chromium on musl might have sandbox issues in GPU process. --in-process-gpu could help diagnose. Let me get stderr for GL_EGL combo with --enable-logging=stderr, grep for angle/egl/swift lines.

Also worth trying: --disable-gpu (forces software compositing; WebGL then uses... in newer Chromium, WebGL with --disable-gpu still works via SwANGLE in the GPU-less path? Actually --disable-gpu disables WebGL unless SwiftShader allowed...).

Hmm wait, actually there's another possibility: since Alpine Chromium links musl, SwiftShader Vulkan might need VK_ICD_FILENAMES env pointing to /usr/lib/chromium/vk_swiftshader_icd.json — but ls showed no such json. The VK_KHR_surface error suggests the ICD partially works but lacks WSI extensions (musl build disabled them).

Back to Firefox — since previous run DID get Firefox working, there must be a way. Firefox 151... Let me search Firefox's libxul for the WebGL creation error string to find nearby logic/pref names:

strings /usr/lib/firefox/libxul.so | grep -n "tryNativeGL" — then look at surrounding strings for prefs like "webgl.software". Actually the function WebGLContext::CreateAndInitGLWith... has flags. The string "Exhausted GL driver options" appears in dom/canvas/WebGLContext.cpp:

I don't remember exactly. Let me look for prefs in libxul strings: grep "webgl.software-rendering", "webgl.force-enabled", "webgl.forbid-software", "gfx.webrender.software".

Actually — KEY REALIZATION: maybe WebGL fails because the GPU process or the renderer can't find the fonts/X? No...

Let me check if there's an about:config pref named webgl.software-rendering in FF151 — I can check via libxul strings. If exists, set it true: Firefox 126+ has webgl.software-rendering which uses... hmm I genuinely think I've seen this pref in Firefox source (StaticPrefs list). In StaticPrefList.yaml: "webgl.software-rendering: true/false"? If it exists, it forces software GL (via EGL surfaceless + llvmpipe? or via osmesa?). Let me grep.

Also grep for "EGL_PLATFORM" usage — Firefox GLContextProviderEGL uses eglGetPlatformDisplay with platform from... gfxVars? There's env MOZ_EGL_PLATFORM? Hmm.

Let me grep libxul for these strings (strings + grep, might take ~30s on 150MB). Run in background maybe. Let me do it.

No webgl.software-rendering pref. But EGL_MESA_platform_surfaceless string exists in libxul — Firefox knows about surfaceless platform. When does it use it? In GLContextProviderEGL, headless mode → surfaceless. So headless Firefox SHOULD pick surfaceless... but it failed. Why would eglInitialize fail in Firefox while eglinfo works? Different env! Firefox process env: I passed EGL_PLATFORM etc. via puppeteer env ✓...

Wait — maybe the problem: Firefox's GLContextProviderEGL loads libEGL.so (SONAME) — check /usr/lib/libEGL.so exists (dev symlink)? mesa-egl package provides libEGL.so.1; the libEGL.so symlink comes with mesa-dev? Let me check. Firefox dlopens "libEGL.so" — if missing, EGL provider unavailable → falls back to GLX (native GL) → headless no X → fail → exhausted!

Check: ls /usr/lib/libEGL.so — earlier listing showed libEGL.so.1 and libEGL.so.1.0.0 but I only grepped libEGL* which showed .so.1 and .so.1.0.0 — no plain libEGL.so! Same for libGL.so (there was libGL.so.1... in the list: "/usr/lib/libEGL.so.1", "/usr/lib/libEGL.so.1.0.0", "/usr/lib/libGL.so.1", "/usr/lib/libGL.so.1.2.0" — no unversioned symlinks).

Firefox GLLibraryLoader: tries dlopen("libEGL.so")? On Linux it uses PR_LoadLibrary("libEGL.so")? NSPR may try exact name then with .so.X suffix? NSPR PR_LoadLibrary appends version? Actually Mozilla's LibraryLoader uses dlopen directly with given name: "libEGL.so". If dev symlink missing → fail!

Fix: create symlinks or install mesa-dev. Simplest: sudo apk add mesa-dev (pulls libegl-dev? on Alpine: mesa-dev includes EGL dev). Or manually: ln -s /usr/lib/libEGL.so.1 /usr/lib/libEGL.so. Root needed; do with sudo into /usr/local/lib? Firefox dlopen searches default paths: /usr/lib is in ld path; add symlink in /usr/lib via sudo. Or set LD_LIBRARY_PATH to a dir containing the symlinks.

Let me create /tmp/gllibs with symlinks libEGL.so → /usr/lib/libEGL.so.1 and libGL.so → /usr/lib/libGL.so.1, then LD_LIBRARY_PATH=/tmp/gllibs. That avoids system modification.

Also possibly needs libGLESv2.so symlink? Firefox EGL path uses eglGetProcAddress for GLES functions — no libGLESv2 dlopen needed.

Try: env LD_LIBRARY_PATH=/tmp/gllibs EGL_PLATFORM=surfaceless MOZ_HEADLESS=1 LIBGL_ALWAYS_SOFTWARE=1, prefs webgl.force-enabled, gfx.webrender.software, webgl.out-of-process=false.

Test with diag3-style probe.

Still failing! Hmm. OK so maybe not the symlink. Need REAL diagnostics from inside Firefox. MOZ_LOG modules for GL: "gl", "gfx". Let me get MOZ_LOG to a file and inspect. MOZ_LOG=GLContext:5? Module name in GLContext code is... In gfx/gl/GLContext.cpp: mozilla::LazyLogModule gGLContextLog("glcontext")? something like "glcontext". Let me MOZ_LOG="glcontext:5,WebGL:5" with MOZ_LOG_FILE and read the output. With MOZ_LOG_FILE=/tmp/fflog, files become /tmp/fflog.child-N.moz_log etc.

Let me check what log modules exist: strings libxul | grep -i "glcontext"? Simpler: MOZ_LOG="timestamp,glcontext:5,webgl:5,Canvas:5". Let me just run firefox CLI directly (not puppeteer) to iterate fast:

XDG_RUNTIME_DIR=/tmp/xdg LD_LIBRARY_PATH=/tmp/gllibs EGL_PLATFORM=surfaceless LIBGL_ALWAYS_SOFTWARE=1 MOZ_HEADLESS=1 MOZ_LOG="glcontext:5,webgl:5" MOZ_LOG_FILE=/tmp/fflog firefox --headless --window-size=300,300 --screenshot /tmp/fftest.png file:///tmp/glt.html

with /tmp/glt.html testing webgl2 and painting body green/red. Also prefs via a user.js in a fresh profile dir: use --profile /tmp/ffprof with user.js.

Let me create /tmp/ffprof/user.js: user_pref("webgl.force-enabled", true); user_pref("gfx.webrender.software", true); user_pref("webgl.out-of-process", false);

And /tmp/glt.html:

--screenshot waits a bit for load. Then check PNG color via pngjs.

Also dump log. Run it.

Logs are empty (log module names wrong?) and the screenshot is RED → webgl2 context creation failed in content process. Note: with webgl.out-of-process=false, WebGL runs in the content process — the child logs would show it. Empty logs → module names wrong. Let me find correct module names: strings libxul | grep "mozlog"? Log module names are string literals. For GL: "glcontext"? Let me grep strings for "glcontext".

Actually the log files are EMPTY — maybe MOZ_LOG_FILE requires file prefix creation... it did create files, empty because no log statements matched. Let me verify module name: in Firefox source, gfx/gl/GLContext.cpp has mozilla::LazyLogModule gGLContextLog("glcontext")? Or "GLContext"? Hmm. Let me grep strings for "glcontext" case-insensitive.

Alternative: use MOZ_LOG="GL:5"? Or check quickly via strings.

"GLContextEGL::FindVisual(): Failed to load EGL library!" — this confirms Firefox CAN fail loading EGL library. So the dlopen name matters. My LD_LIBRARY_PATH symlink approach should have fixed that... unless LD_LIBRARY_PATH isn't honored for content processes (sandbox unsets it?) — MOZ_DISABLE_CONTENT_SANDBOX wasn't set in this CLI test! Content process sandbox (seccomp-bpf) blocks dlopen? The sandboxed content process CAN'T open new files (open syscall blocked) → dlopen of libEGL fails! With webgl.out-of-process=false, GL loads IN the content process → sandbox blocks → fail. That's likely the root cause of everything!

Fix: MOZ_DISABLE_CONTENT_SANDBOX=1 (and we had that in config A/D for puppeteer but those still failed... hmm, but maybe the sandbox wasn't the only issue — LD_LIBRARY_PATH wasn't set in A/D! Right: configs A-D lacked LD_LIBRARY_PATH AND D had sandbox disable. Config D had MOZ_DISABLE_CONTENT_SANDBOX=1 + MOZ_DISABLE_GPU_SANDBOX=1 but no LD_LIBRARY_PATH (no libEGL.so symlink) → dlopen fails.

So combine BOTH: LD_LIBRARY_PATH=/tmp/gllibs + MOZ_DISABLE_CONTENT_SANDBOX=1 + EGL_PLATFORM=surfaceless + out-of-process=false.

Alternatively better architecture: keep WebGL OUT of process (default) so GL loads in GPU process (unsandboxed-ish), then LD_LIBRARY_PATH alone may suffice. Let me test CLI with both combos quickly.

Combo 1 (in-process, no sandbox): MOZ_DISABLE_CONTENT_SANDBOX=1 LD_LIBRARY_PATH=/tmp/gllibs EGL_PLATFORM=surfaceless LIBGL_ALWAYS_SOFTWARE=1 MOZ_HEADLESS=1, prefs webgl.out-of-process=false + force-enabled.

Combo 2 (out-of-process default): pref webgl.out-of-process=false removed (default true) + MOZ_DISABLE_CONTENT_SANDBOX still set (harmless) + LD_LIBRARY_PATH.

CLI screenshot check px color. Run combo 1 first; if red, combo 2. Do both in one command sequentially.

Still red. Ugh.

Let me get REAL log output. The MOZ_LOG files were empty. Maybe logging needs correct module names. Let me search strings for log module declarations — they're usually short lowercase words. Common gfx log modules: "gfx", "webgl", "glcontext"... my "webgl:5" should have matched WebGL module ("webgl"). Empty files suggest MOZ_LOG didn't initialize — maybe MOZ_LOG_FILE needs MOZ_LOG to include something valid, or in release builds logging is compiled out? Firefox release builds have MOZ_LOGGING enabled (it's on by default even in release? NSPR logging yes, MOZ_LOG in release: only if --enable-logrefcnt? Actually MOZ_LOG works in release builds).

Hmm wait — maybe the child content process never even rendered the page with my script because... the screenshot showed red bg, so script RAN. So WebGL context failed in child. child logs /tmp/fflog.child-*.moz_log were created (exist) but my grep filtered them... In the earlier run I grepped with pattern "egl|gl|fail|error" and got nothing, then cat ... | head -80 gave NOTHING at all — empty files indeed.

Let me test MOZ_LOG works at all: MOZ_LOG="nsHttp:5" should produce tons of output... Or simpler: run with MOZ_LOG="all:1"? Massive. Let me try "timestamp,sync,WebGL:5"? Hmm.

Actually! Another idea: maybe the issue is GLContext creation happens but eglChooseConfig fails because we request a visual (X11) in headless? The string "GLContextEGL::FindVisual(): Failed to load EGL library!" — FindVisual is for X11 path. If headless uses surfaceless, no visual needed.

Better diagnostic: strace! Is strace available? apk add strace (main repo). Trace the content process open/dlopen attempts: strace -f -e trace=openat,access -o /tmp/strace.log firefox... then grep libEGL. That tells exactly what Firefox tries to load.

Also, sanity check: does eglinfo work via LD_LIBRARY_PATH only? Irrelevant.

Install strace and trace combo 1.

No libEGL/libGL/dri lines at all in strace — meaning no process even TRIED to open any GL library! So GLContextProviderEGL wasn't even attempted. WebGL creation bailed BEFORE trying to load GL.

Why? WebGLContext::Create checks... GfxInfo blocklist! Even with webgl.force-enabled? force-enabled bypasses blocklist I thought. Hmm, but maybe: headless + software webrender → WebGL requires "GPU acceleration"? No...

Wait — maybe the decision: WebGLContext::CreateAndInitGL requires gfx::gfxVars::UseWebRender()... no.

Look at the strace for ANY .so loads beyond startup? Content processes are forked... strace -f should cover children. Let me check if strace log has content (grep -c). Maybe strace with -e openat and firefox launcher script — /usr/bin/firefox is a shell script wrapper! strace traces the shell; exec of real binary continues traced? fork+exec of /usr/lib/firefox/firefox should be traced with -f. Let me verify the log size and grep 'firefox'.

Also possible: Firefox's WebGL refuses because compositing failed: "RenderCompositorSWGL failed mapping default framebuffer, no dt" — canvas/WebGL needs a "dt" (DrawTarget)? In headless, no widget surface... But WebGL offscreen should not need that.

Alternative approach — GIVE UP on Firefox, try harder on Chromium. Chromium's GPU process DID try (we saw ANGLE/Vulkan errors). Chromium SwANGLE fails due to VK_KHR_surface missing in musl SwiftShader Vulkan. Options for Chromium:

• Use system Mesa via ANGLE gl-egl backend: we tried --use-gl=angle --use-angle=gl-egl, failed. Need to see logs why. Maybe it still tried Vulkan first and crashed GPU process. Also musl + Chromium's bundled swiftshader... The gl-egl backend dlopens system libEGL — musl Alpine chromium links against system libEGL? Chromium bundles its own libEGL.so (ANGLE). With --use-angle=gl-egl, ANGLE loads SYSTEM libEGL (via eglGetDisplay? no — ANGLE's "gl" backend dlopens libEGL.so.1/libGL from system). We saw "SwANGLE failed" in earlier log (that was default). With gl-egl it may fail differently — I didn't capture logs for that attempt!

Let me run chromium gl-egl with --enable-logging=stderr and inspect. Also add LD_LIBRARY_PATH=/tmp/gllibs so system libEGL.so resolves. And env EGL_PLATFORM=surfaceless.

Actually wait, for Chromium there's another flag: --use-gl=egl (native EGL, not ANGLE) — deprecated but might exist in Chromium 142? It said "Initialization of all (1) EGL display types failed" earlier for SwANGLE.

Also: --use-angle=default picks vulkan→swiftshader fails. gl-egl should hit system EGL.

Let me run diag with logging for gl-egl and egl: args: --use-gl=angle --use-angle=gl-egl --enable-logging=stderr --v=1, env LD_LIBRARY_PATH=/tmp/gllibs EGL_PLATFORM=surfaceless LIBGL_ALWAYS_SOFTWARE=1.

Capture stderr to file, grep angle/egl/error lines.No GL library opens at all — Firefox bails before trying. Chromium at least tries (ANGLE). Let me capture logs for Chromium's gl-egl backend with system Mesa:

Logs are empty now too — dumpio:false means no browser stderr piping; --enable-logging=stderr writes to the browser's stderr which isn't captured without dumpio. Let me set dumpio:true and capture node's stderr (which includes browser output piped through). Earlier diag5 had dumpio:true and got logs.

Actually with dumpio:true, browser stderr goes to node process stderr → /tmp/chX.log would have it. I had dumpio:false here. Redo with dumpio:true. But is time better spent elsewhere?

Reality check on time budget: 50% time threshold already passed a while ago (that checkpoint was at iteration 1... wait, "iterationProgress":0.024, "timeProgress":0.50 — half the TIME budget consumed). Remaining ~50%. Must converge.

Decision point. Let me think about what's most promising:

Firefox: doesn't even try to load GL → some early bail. Maybe GfxInfo blocklist marks GPU as failed → WebGL refused before GL attempt. webgl.force-enabled should bypass... unless the issue is webgl.out-of-process parent/child plumbing fails first. The empty strace for libGL across ALL processes (I grepped whole file — strace -f includes all PIDs in one file) means even the GPU/parent process never tried. In the puppeteer diag runs earlier, the ERROR "tryNativeGL → exhausted" came from the CONTENT process attempting... with out-of-process WebGL, the content process asks GPU process via RemoteCanvas — the "WebGL creation failed: tryNativeGL" message format matches the IN-PARENT? Hmm no.

Wait, actually in combo with 'webgl.out-of-process': false, the content process creates GL directly and logs "tryNativeGL". In the strace CLI run, profile had webgl.out-of-process=false (user.js combo1)... but NO libGL opens at all. Confusing. Unless strace missed because dlopen uses openat with full path — I grepped "libEGL|libGL|dri|EGL" — even "EGL" anywhere — nothing. So zero attempts.

Hypothesis: WebGL disabled due to GPU process blocklist state recorded in the profile from previous crashes → all WebGL attempts refused early with "exhausted drivers"? Fresh profile each puppeteer launch though. My CLI runs reused /tmp/ffprof across attempts (with prior crash records?). First puppeteer runs used fresh profiles and still failed.

Deeper hypothesis: GfxInfo blocklist: On Linux without X, gfxInfo fails → "GPU process disabled"? In headless, GFX features: webrender software. WebGL in content requires "shared GL" from parent/GPU process for compositing interop? In FF, WebGL canvases are presented via RemoteTexture; creation requires a "WebGLBridge" to the GPU/parent process; if the GPU process failed to init GL, WebGL creation refuses with exhausted drivers — and the GPU process SHOULD have tried EGL... but strace showed no EGL attempts anywhere. Maybe GPU process doesn't exist in headless (GPU disabled) → WebGL in content falls back to "in-parent"?

Honestly, I'm burning time. PIVOT: maybe use X. No xvfb package in repos (search broken earlier due to cache warnings; sudo apk add with --no-cache worked). Try sudo apk add xvfb directly — Alpine main has xvfb? Let me just try installing: sudo apk add --no-cache xvfb. If not found, try xorg-server-xvfb.

With Xvfb:

• Firefox non-headless (headless:false) with DISPLAY → GLX via Mesa swrast works → WebGL works. This is a very well-trodden path.
• Chromium non-headless with DISPLAY: --use-gl=angle --use-angle=gl (GLX) → system Mesa GLX → llvmpipe → WebGL.

Xvfb route is classic and reliable. Do it now.

Xvfb installed. Start Xvfb :99, then test Firefox non-headless with DISPLAY=:99:

• user.js prefs: webgl.force-enabled, gfx.webrender.software (compositing: with X, GPU disabled? headless off, puppeteer headless:false launches with a real window on Xvfb).
• Env: DISPLAY=:99, LIBGL_ALWAYS_SOFTWARE=1 (Mesa GLX → llvmpipe), no EGL_PLATFORM (default X11 platform works under Xvfb), MOZ_DISABLE_CONTENT_SANDBOX=1 maybe not needed now (GLX loads system libGL fine — content process sandbox: with out-of-process WebGL (default), GL runs in GPU process; GPU sandbox might block? Set MOZ_DISABLE_GPU_SANDBOX=1 to be safe; sandbox level prefs... just include the disables).

Test via CLI screenshot first (fast, no puppeteer): firefox --width... plain firefox without --headless needs DISPLAY; run: DISPLAY=:99 firefox --profile /tmp/ffprof2 --window-size=300,300 --screenshot? --screenshot forces headless mode! So for non-headless test I need puppeteer or use xvfb-run with --headless?

Hmm: with DISPLAY set, does --headless still fail? Headless ignores X. Use puppeteer headless:false.

Quick CLI check without screenshot: run DISPLAY=:99 LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep renderer to confirm GLX llvmpipe under Xvfb first. Then puppeteer firefox headless:false probe.

Note: puppeteer firefox headless:false — supported? Puppeteer Firefox non-headless works (it's just normal mode). OK.

Also for window manager: none needed.

Sequence:

1. Xvfb :99 -screen 0 1280x800x24 & (background, then test).
2. glxinfo check.
3. puppeteer firefox headless:false, env DISPLAY=:99 LIBGL_ALWAYS_SOFTWARE=1 MOZ_DISABLE_CONTENT_SANDBOX=1 MOZ_DISABLE_GPU_SANDBOX=1, prefs webgl.force-enabled etc. probe webgl2.
4. If FF works → great. Else try chromium headless:false --use-gl=angle --use-angle=gl (GLX) probe.

Run Xvfb with nohup & disown in shell command; Xvfb persists across tool calls? Each execute_shell_command is a new shell but background processes persist (nohup). Use nohup Xvfb :99 -screen 0 1280x800x24 >/tmp/xvfb.log 2>&1 & then sleep 1 and check.

*************************************************************************************************99.

FIREFOX WORKS! WebGL2 + llvmpipe + EXT_color_buffer_float under Xvfb, non-headless.

Working recipe:

• Xvfb :99 running
• puppeteer.launch({ browser:'firefox', executablePath:'/usr/bin/firefox', headless:false, extraPrefsFirefox: { webgl.force-enabled, gfx.webrender.software, webgl.out-of-process:false }, env: { DISPLAY:':99', LIBGL_ALWAYS_SOFTWARE:'1', GALLIUM_DRIVER:'llvmpipe', MOZ_DISABLE_CONTENT_SANDBOX:'1', MOZ_DISABLE_GPU_SANDBOX:'1' } })

Interesting: out-of-process:false + content sandbox disabled — probably the key combo (GL loads in content process, dlopen needs sandbox off). Whatever — it works!

Now update the test script test.mjs to use this launch config, and run the full validation suite on demo 058. The demo at q=low for most; also test q=medium (autodetect will use TIER override? no — autodetect checks context; llvmpipe → Renderer antialias etc. For medium/high tests I'll use ?tier=medium explicit, but earlier q param notes: 'q=medium' also sets tier. I have both q and tier params: q sets quality tier incl. resolution; tier= overrides feature tier only. For headless tests use q=low&heads=300 etc.

Update /tmp/ptest/test.mjs launch section:

Then run: node test.mjs — runs 5 subtests (q=low, q=medium, q=high, fallback test with q=low, autodetect). Timing: llvmpipe rendering of this demo at 500x360 low tier — each frame maybe 50-200ms; head battles up to 4min at 150 heads each... way too slow. Use q=low&heads=30 for the head battle in q=low run? That changes sim slightly but fine. Actually let's keep heads=150 but it'll be slow — 150 heads × ~30 gens × 6 sim steps... sim time is the same regardless of rendering; wall time per gen maybe 2-5s with llvmpipe → up to 2-3 min per run. The autodetect run will pick... WebGL2 available → context attrs from renderer... my autodetect uses renderer.getContext().getContextAttributes() — always true → tier 'high'! Wait:

Autodetect gives 'high' under llvmpipe — high tier on llvmpipe will be SLOW (shadows 2048, kinesin trails 64, 70 sim steps, 600 particles). The autodetect run heads=12 only; sim short. OK but rendering high tier at 500x360 llvmpipe maybe 1-3 fps → fine for a test (we only need INFO data + one screenshot).

Total runtime estimate: 5 runs × (launch ~10s + sim up to 3min) ≈ 10-15 min worst case. Acceptable, but to be safer, reduce: q=medium heads=80, q=high heads=40? Let me keep script as-is but lower: q=low&heads=150→ keep; medium→heads=60; high→heads=25; autodetect→heads=12 (high tier, short). Fallback test quick. Actually sim budget: headsN=150 gens up to 30 → worst ~150×30×6 = 27k head-steps... sim cost tiny. Rendering: every generation we render ~1 frame per generation in simToSteady (render once per generation after stepping, to keep rAF loop alive... actually render happens inside the generation loop once per gen: if (generation % 1 === 0) updateLayersFromGrid(); renderer.render(...) — yes once per gen + once in trial loop). ~30-60 renders per run. At llvmpipe low tier 500x360 → maybe 100ms/frame → seconds. Fine.

But ALSO: the final Promise.race timeout 420s per run. OK.

One issue: page.goto(url, { waitUntil: 'networkidle0' }) — unpkg CDN access needed; earlier runs reached unpkg fine (console showed three.js errors from unpkg module). OK.

Also screenshot dir /tmp/ptest/shots — exists.

Edit test.mjs launch block, then run. Use timeout 300000 max per command; full suite may exceed 5 min! The tool timeout max is 300000ms (5min). The suite with 5 runs could take 10+ min. Solution: run test.mjs in background with nohup, poll output file. Let me do that: cd /tmp/ptest && nohup node test.mjs > /tmp/ptest/test-out.log 2>&1 & then poll with tail.

Also make each sub-test fail-soft: if INFO timeout (420s) → catch → continue next. Current code: await page.waitForFunction(..., {timeout:420000}) throws → whole script exits. Wrap each run in try/catch. Let me edit the run() function to catch errors and record.

Let me rewrite test.mjs cleanly with:

• launch config as above
• run(name,url,timeoutMs) with try/catch
• runs: low(150), medium(60), high(25), fallback, autodetect(12)
• write JSON summary at end + console lines.

Then background-run it.WebGL2 works! llvmpipe + EXT_color_buffer_float. The winning recipe: Xvfb + Firefox non-headless + webgl.out-of-process:false + disabled sandboxes. Now updating the test suite to use this config and making it fail-soft:

Wait — the fallback test (?q=low&test-fallback): with the fallback grid path, window.__MICRO_INFO.done — the fallback path sets __MICRO_INFO with fallbackShown and... does it set done? Looking at runGridFallback: it sets __MICRO_INFO = { fallbackShown, webgl2, renderer, reason } — never sets done or error! So waitForFunction would time out (420s wasted). Fix the fallback run: for that one, wait for window.__MICRO_INFO existence only, short timeout. Let me tweak: run('fallback', ..., 20000) and modify waitForFunction predicate? Simpler: add a flag to run() — waitAll=false → wait for __MICRO_INFO only:

predicate: window.__MICRO_INFO && (window.__MICRO_INFO.done || window.__MICRO_INFO.error || ******************************own)

That covers fallback (fallbackShown set immediately) ✓.

Also heads for q-low=150 at llvmpipe might take a while; timeout 420s each. Whole suite worst case ~35 min. Run in background and poll.

Edit the predicate, then launch in background.

80% of max time consumed! Only ~20% left. I must hurry. Launch the test suite in background NOW and poll. If the full suite is too slow, I'll cut it down.

Actually, given time pressure, let me reduce scope of the automated run: run q-low (heads=80) + fallback + autodetect — skip medium/high (they're the same code path with different params; low validates the path; high tier risk is only perf). But medium/high have tier-specific features (shadows, trails, HIT/HRT) that could crash shaders (e.g., 1D texture shader path used for trails only at high? No — trails texture used at all tiers for pheromones; history LUT only when trails>0 i.e., medium/high; shadow shader only medium/high!). To validate shaders at high tier, one quick run with heads=3 would exercise the shader compile + a few frames fast. Let me modify: q-high heads=3 (compiles shaders incl. shadows + history, renders a few frames, short sim), q-medium heads=5. That keeps runtime small while covering shader compilation paths.

Sed-edit the run lines: q-medium heads=60→8, q-high heads=25→4, q-low heads=150→80, autodetect heads=12→6. Then background-run.

*****************************************************************************************************************************************************************************************************************************************ll.

*******************************************************************************************************************************************************************************************nd.

Server is down. The pkill command earlier caused the shell to fail (exit -1) — probably pkill matched the shell's own command line ("http.server" appears in the bash -c command string!) and killed the shell itself. That's why exit -1: pkill -f "http.server" killed the current shell process. Avoid pkill patterns that match my own command.

Start server in background — use a python script file approach to keep the pattern out of my command line, or just don't use pkill at all.