Fluid simulation · hy4

We need build index.html self-contained interactive 2D fluid dye simulation. Need use browser tool inspect initial/console and brief representative checks. Need likely implement robust stable fluids on Canvas 2D maybe WebGL. Need think carefully, ensure actual velocity/dye advection and persistence, momentum/dye after release, gradual dissipation, initial seed, controls color, pause/resume, clear, bounded resolution/work performance at 1200x800. Need make verification via browser interactions and perhaps sampling imagery / motion. We have browser tool actions reload inspect screenshot motion click drag key type scroll. Need know what inspect returns. Let's inspect cwd first maybe just empty.

We need design. Could implement GPU WebGL2 fluid sim for quality, but complexity and browser environment may support WebGL maybe software. Canvas 2D CPU stable fluids with low grid 160x100 perhaps enough, bilinear advection and pressure projection via Jacobi. Need maintain velocity and RGB dye. Full-screen canvas upsample via ImageData at low resolution. Work bounded. At 1200x800 use e.g. sim grid 160x107 (~17k cells), pressure iterations 12-18, each frame operations ~ several million; JS likely okay, 60fps? Need optimize. Could use 128x85 or 160x108. Want responsive. Need persistent swirls. Stable fluids algorithm:
- arrays u,v,u0,v0,r,g,b,r0,g0,b0,p,div, maybe Float32Array.
- boundary: velocity reflect/no-slip at walls; dye clamp.
- forces: drag splats add Gaussian velocity and dye.
- advect: semi-Lagrangian backtrace from previous velocity field, bilinear sample; for dye use velocity at perhaps cell itself; for velocity itself use same field. Need conserve-ish.
- projection: compute divergence, solve Poisson p with Jacobi/Gauss-Seidel, subtract gradient. This produces incompressible swirls. We need initial momentum/dye seeded. Could seed several Gaussian vortices and dye blobs. Dye persists with decay e.g. 0.997 / frame adjusted dt. Velocity dissipation ~0.995 maybe. Need frame-rate normalization robust.
- perhaps vorticity confinement to promote visible swirls; optional. Stable fluid with projection and initial vortices + drag will work. Add a little vorticity confinement from curl gradient to enhance swirls, but could destabilize / processing cost. Implement dt relative to 16.67ms; maybe fixed step at 1/60 with accumulator capped. We can use fixed simulation steps, max 2 per frame to keep responsiveness; perhaps render each frame. dt fixed 1 (grid units interpretation).
- controls color selector perhaps custom palette buttons plus input type=color. Need make accessible, semantic.
- Pause/Resume button toggles pausing simulation but perhaps pointer still can inject? Could allow injection while paused? Requirement pause/resume likely simulation paused; no dye while paused maybe pointer action could still prime. But drag through canvas while paused possibly gets no update. We can support injection while paused and render static. Clear resets all arrays including velocity/dye and seed? "Clear removes dye

and resets velocity; the next drag can start a new flow." So clear should not seed initial scene again. Can have initial seed only startup. If clear while paused stay paused; next drag may not show flow until Resume—could be annoying but acceptable? Better clear also resumes? Maybe clear simply clears arrays, leaves pause state but perhaps drag will inject dye visible (we can render splat when paused), but flow won't evolve. Requirement next drag can start new flow likely need ensure if paused clear perhaps resume automatically? Could choose Clear to reset and automatically resume if paused, or leave paused. Usually clear independent. But for verification browser may click clear while paused? Could support auto resume on clear with notice? We can make clear sets running true and updates button, to guarantee. Or preserve state but allow drag to inject and render; no flow until resume. Better Clear resumes by default so next drag starts flow. Need check. Need implement robust controls overlay over canvas; pointer coordinates based on canvas size; pointer capture; prevent scrolling/touch default.

Alternative WebGL2 fluid simulation with beautiful smooth rendering and high resolution 256x171. But complexity and potential WebGL support issues. CPU stable fluid can be robust and no external. Need ensure image visual quality; perhaps render ImageData scaled with smoothing onto full canvas and overlay subtle gradients? Could use canvas at sim resolution and CSS scaled with image-rendering maybe default smooth via drawImage. Main canvas sized physical viewport with devicePixelRatio capped 1.5? Full-screen. We can create offscreen low-res canvas with ImageData; drawImage smoothed to main canvas. Need avoid network. Could add subtle vignette/background, maybe all visual via CSS. Need ensure dye on black/dark background. Simulation RGB values additive style (0..1 / 0..255). Need map to color with tone mapping / alpha perhaps:
- dye channels r,g,b stored intensity 0..something. On clear black.
- rendering each pixel rgb = (1 - exp(-r*exposure)) * 255 plus perhaps baseline dark navy. But if using dye colors globally, mixing occurs. Use additive color handling.
- Canvas background black/navy; draw low-res image opaque with base RGB (e.g. [4,7,14]) + color. Need note output maybe interpolation.
- Optionally add tiny glow by drawing low-res canvas onto main with filter='blur(...)' globalAlpha maybe heavy if full-screen; can draw blur from low-res at scale. But filter could be costly. Maybe use two

passes: main drawImage with imageSmoothingEnabled=true, then overlay same with globalCompositeOperation='screen', ctx.filter='blur(18px)', alpha .3. At 1200x800 could be okay; but WebGL-less canvas filter might hurt performance. Could use CSS box-shadow? Better no blur.

Need likely output elegant UI. Requirements focus functionality. Let's design simulation carefully and test with browser tool. Need understand browser tool outputs perhaps screenshot attachments. We'll create then reload/inspect.

Let's derive stable fluid algorithm.

Grid size based on viewport:
const SIM_MAX_W=180, SIM_MAX_H=120 maybe dynamic aspect. To preserve cell aspect square: choose scale = sqrt((w*h)/(~180*120))? Need bound resolution. Easiest choose target width 160, target height = Math.round(160*h/w), clamp <=140. At 1200x800 -> 160x107 = 17,120. Or target grid area ~18000, compute cellSize=Math.sqrt(w*h/18000) ~7.3 px; GW=ceil(w/cellSize)=164, GH=109. Use max 192x128. Need cap both. Sim aspect can use separately scale x,y but velocity coordinates need scale properly. If square cells, grid aspect matches viewport. Choose:
const CELL_TARGET = Math.max(6, Math.sqrt(w*h/18000)); W=Math.min(192, Math.max(80, Math.ceil(w/CELL_TARGET))); H=Math.min(128, Math.max(54, Math.ceil(h/CELL_TARGET)));
At 1200x800: cell sqrt(960k/18000)=7.303; W=165,H=110; aspect 1.5 vs viewport 1.5. At smaller 800x600: cell 5.16 but clamp 6 => 134x100, aspect 1.34 vs 1.33. Fine.
Maybe fixed 144x96 simplifies; at 1200x800 cells 8.33 x 8.33. Use fixed resolution scaled to viewport aspect: H = round(144 * h/w), cap 128. At 1200x800 H=96. Grid 13,824 cells. Good performance. At portrait huge H cap leads distorted cells but okay. Could compute area-based grid with square cells. Need pointer mapping from CSS pixel to grid coordinates. Fine.

Indexing: idx(x,y)=x+y*W. Arrays Float32Array

N. We can include boundaries as normal cells and enforce. Use 1..W-2 interior.

Advection:
function advect(dst, src, u, v, dt, dissipation) {
 for y=1..H-2:
  for x=1..W-2:
    // velocity at cell? u[idx],v[idx] in grid cells per unit dt maybe.
    px = x - u[i] * dt;
    py = y - v[i] * dt;
    clamp px [0.5, W-1.5], py...
    x0=floor px; x1=x0+1; sx=px-x0; etc.
    val = bilinear(src,...)
    dst[i]=val*dissipation
 boundaries via setBoundary depends scalar vs u/v; can copy src at boundaries or enforce.
}
If velocities are in grid cells per tick, drag forces e.g. pointer delta in grid cells scaled ~0.4? Need calibrate. Suppose drag across 600 CSS px in 300ms ~20px/frame -> 2.4 cells/frame. We could add velocity proportional to dx * 0.8 = ~2 cells/tick; fluid moves 2 cells per tick. Good. Need precise pointer event mapping: pointer prev in grid coords; dx=x-prevX, dy=y-prevY, perhaps dt normalized. Add splat velocity force = dx * 1.2. If pointer events at 60Hz, dx ~2 cells; force ~2.4. If pointer event bursts, maybe force additions multiplied each event, could be large. Use an accumulated pending splats applied per fixed simulation frame? Better inject on pointermove using velocity computed from movement / elapsed time, and Gaussian splat add force proportional to dx. But pointer event interval variability. Could store queued splats and apply each simulation step. If multiple pointer moves, each adds force/dye. Fine with scaling and clamp.

Need support drag through canvas with browser drag action perhaps action coordinates toX/toY; likely browser tool performs one drag from x,y to toX,toY perhaps with intermediate moves? Could be one pointermove endpoint, that still inserts a line? Need bridge gap between pointer positions to ensure dye follows drag. In pointer handler, interpolate along segment from old pos to new pos and add Gaussian splats every e.g. 1.2 grid cells. That ensures continuous stroke regardless of event frequency. Add momentum along direction at each splat. Need calculate force based

on segment dx,dy with consistent scaling. If call splat for each step, perhaps total momentum integrated but velocity locally added many times. We can set strength per unit distance. For examples:
- each segment step length s = 1 grid cell. For each splat add velocity force vx = dirX * speedScale (e.g. 1.2) and dye = color * 0.3. If 100 splats along stroke, each affects ~radius 4 cells; overlapping locations get accumulated -> massive. Need distribute by step density and avoid huge concentrations. Could use force = dxPerSplat * 0.8, where dxPerSplat ~1 cell => 0.8. Each point receives ~radius*2 overlap ~8 => 6.4 cells/tick, possibly too high but okay with clamping. Dye amount e.g. 0.12 per splat -> concentration ~1, okay.
- alternative use per event one Gaussian at midpoint with anisotropic elongated radius? Hard.
- queue one splat per e.g. 2 grid cells, Gaussian radius 5. Force = dx_total? direction * 1.8 each; dye 0.28. Overlap 5 -> 9 cells/tick; clamp max velocity maybe 8. That creates strong flow.
- maybe use normalized dt; dt fixed 1. Need velocities stable with CFL; semi-Lagrangian stable for high velocity, pressure projection. Clamp velocities to ±8 cells/tick to avoid sampling too far and weirdness.
- injection radius ~5-7 cells. Dye color values maybe 0..3, decays. Need make visible.
- color selector input color; convert hex to linear-ish RGB 0..1; dye channels add color * intensity. Could boost saturation.

Pressure solve:
divergence:
div[i] = -0.5 * (u[i+1]-u[i-1] + v[i+W]-v[i-W]); maybe if grid spacing 1. Then p=0; solve p=(div + p neighbors)/4 (Jacobi) depending sign. Standard Jos Stam:
div = -0.5 * (uR-uL+vD-vU)/N; p=0; lin_solve(p,div,1,4); then u -= 0.5*N*(pR-pL); v -= 0.5*N*(pD-pU). With N=W maybe. Simpler:
div = 0.5*(uR-uL


+vD-vU);
solve ∇²p = div: p = (pL+pR+pU+pD - div)/4
u -= 0.5*(pR-pL); v -= 0.5*(pD-pU)
This should project. Need verify sign. For velocity field with divergence d = 0.5(uR-uL + vD-vU). Want Δp = d, then u_new = u - grad p. Discrete divergence_new ≈ d - Δp = 0. Discrete Laplacian p = pL+pR+pU+pD-4p. Setting (sum -4p)=d -> p=(sum-d)/4. yes. Then gradient 0.5*(pR-pL). Good. At boundaries enforce no-slip: for u left/right, u[boundary] = -u[interior] maybe; v at left/right = v[interior]; at top/bottom v=-v[interior], u=u[interior]. Pressure boundary p[boundary]=p[interior] (Neumann). To make fluid swirl rather than escape, no-slip. Need write setBoundary functions for u,v and p/dye.

We can use loops over rows and cols to set boundary values after each operation. For scalar dye boundaries copy neighboring interior. For velocity, after projection set:
u[0,y] = -u[1,y]; u[W-1,y]=-u[W-2,y]; v[0,y]=v[1,y]; v[W-1,y]=v[W-2,y]
v[x,0]=-v[x,1]; v[x,H-1]=-v[x,H-2]; u[x,0]=u[x,1]; u[x,H-1]=u[x,H-2]
corners average. Could define separate setVelocityBoundary(u,v). Similar for p Neumann (copy). Need no allocations in loops. Jacobi uses p and pTmp; swap references, need variables `let p = ...; let pTmp=...`. Could do 16 iterations. Need p initial zero each step, then loop. Could use 12 iterations to bound work. At 14k cells *12 ~170k plus advection ~100k, fine. Actually 5 advect fields each ~14k=70k bilinear 4 loads, pressure ~170k, render ~14k, total ~300k operations per step, likely ~5

ms JS. Good.

Advection order:
- add forces/dye queued
- project u,v to make source velocity divergence-free? Typically sequence:
  addSource velocity
  diffuse (skip)
  project
  advect u,v using previous velocities (copy u->u0,v->v0)
  project
  for dye advect with u,v.
Could simplify:
  apply splats to u,v,dye
  project(u,v)
  copy u,v to u0,v0
  advect u0 backtrace using u0,v0 -> u (or using same velocity field)
  advect v0 -> v
  project(u,v)
  copy r,g,b -> tmp arrays
  advect dye using u,v -> r,g,b
  apply dissipation
  maybe vorticity confinement before projection.
Need careful not to overwrite u before advect v uses u0,v0. We can use u0/v0 as sources; write into u/v. `advect(u, u0, u0, v0, ...)`, then `advect(v, v0, u0, v0, ...)`. Good.
Dye sources: have `r0,g0,b0` arrays as temp; copy typed arrays `.set(r)` etc, then advect each into r,g,b using u,v. Need also maybe dye diffusion slight; bilinear advection itself diffuses. Add `dissipation = Math.pow(0.995, dt)`; at fixed dt 1. Velocity dissipation = 0.997 maybe. Need "gradually dissipate" but persistence after release. Dye half-life at 0.995 per frame = 138 frames ~2.3s; maybe too fast. Use 0.9985 half-life 462 frames ~7.7s; 0.999 = 11.5 sec. Good. Momentum 0.997 half-life 3.8s. Need visible swirling after release ~2-5 sec. use velocity 0.996? half-life 2.9s; vorticity confinement can sustain. Need gradual dissipate and eventually fade. Use 0.9975 velocity, 0.9988 dye. At 60fps, dye half-life 9.6s. Fine.
But pressure projection dissipates energy too. Vorticity confinement is needed to produce persistent swirls. Implement confinement:
curl[i] = 0.5*(v[i+1]

-v[i-1] - u[i+W]+u[i-W]) maybe standard curl = ∂v/∂x - ∂u/∂y.
Find magnitude gradient `gx = abs(curlR)-abs(curlL)`, `gy=abs(curlD)-abs(curlU)`, normalize; force = epsilon*(gy? etc). Standard:
N_x = 0.5*(|ωR|-|ωL|), N_y=0.5*(|ωD|-|ωU|); normalize N; f_x = epsilon * (N_y * ω); f_y = epsilon * (-N_x * ω). Need sign conventions. Could add force to u,v each frame. Use eps maybe 0.12-0.3. This enhances vortices. Need avoid noise. Or skip because projection + drag naturally creates vortex rings; on a 2D drag line, injection creates dipolar vortex that travels and persists. Initial seed with multiple vortices can give swirling. Might be sufficient.

Need seed initial scene: create several Gaussian dye blobs and swirling velocity fields. Could use `addVortex(cx,cy,radius,strength)` where tangential velocity around center:
for cells within radius*2:
 f = exp(-(dx²+dy²)/(2r²)) * strength;
 u += -dy/r * f; v += dx/r * f;
dye splats colored at centers.
Also maybe global gentle field around center. Need seed small amount, visible on load. Use 3 or 4 colored dye blobs with vortices, perhaps one center orange, cyan, magenta. Needs be "small amount" not full screen. Dye blobs radius 7-10 cells. Vortices radius ~14-20. No animation before any interaction. We can add 3 vortex swirls with color. But pressure projection will make divergence-free from tangential field, okay. Need dye follow swirls. We can also add linear momentum to cause movement. If initial vortices stationary, dye rotates around center and persists, satisfying "colored dye and motion". Good. A pair of counter-rotating vortices? Need visible swirling flow. Use:
vortex at (0.35W,0.45H), r=0.12*min(W,H), strength=2.8 color cyan
vortex at (0.62W,0.55H), r=0.14*min..., strength=-3.2

color magenta
vortex at (0.5W,0.3H) perhaps orange, strength=1.8.
Each dye blob maybe ellipse offset from center to show rotation. Add splats around center / central blob. Need avoid clutter UI overlay. UI top-left panel maybe occupies x<300, y<120; initial scene centered.

Drag injection:
- Color input plus preset swatches perhaps. Requirement "color selector" can be `<input type="color">`, plus swatches for quick. Need ensure browser tool can interact maybe type? Clicking color input opens OS dialog not easy; swatches can be clicked. Use buttons with data-color and hidden/visible input. Need expose JS maybe browser inspect can call global functions? Could include diagnostic API `window.__fluid` with state and sample functions to verify. Browser tool inspect maybe DOM/console; we might be able to use `bash` to run node? No browser evaluate tool beyond inspect perhaps inspect returns JS? Let's see. The `browser` tool actions: reload, inspect, screenshot, motion, click, drag, key, type, scroll. No explicit evaluate. But inspect may include console and DOM snapshot. We can set debug state visible in DOM perhaps add status text with metrics. For verification, we can use screenshots and maybe CSS DOM. Could expose simulation metrics in an element `<output id="debug">` updated perhaps max dye/velocity, useful to check clear/second drag. But unnecessary user-facing maybe include small HUD showing status / hint. Could add diagnostics hidden `data-*` attributes to document body and update per frame, so inspect can read. We could include `document.documentElement.dataset.dye`, `dataset.speed`, etc. Browser inspect likely returns DOM with attributes? Need check. We can also use browser screenshot attachments visually. Motion tool likely captures frames/reports movement. Need introduce maybe a debug overlay enabled via query or keyboard? Since no external, can perhaps show a small stats line "sim 164×110 • active dye". That's nice. But verify dye follows drag with screenshots and motion. Need perhaps use browser motion action; likely returns multiple frames and detects motion. We'll use.

Need ensure pointer events from browser tool. `drag` likely uses mouse pointer events with x,y,toX,toY. Need listen to `pointerdown`, `pointermove`, `pointerup`; browser tool might dispatch mouse events instead. Better listen to both pointer and mouse? Pointer events are standard and browser automation likely dispatch mouse events

that generate pointer events in Chromium. To be safe, handle `mousedown/mousemove/mouseup` too but avoid duplicate injection when both pointer and mouse generated. Could use Pointer Events only and also fallback if `window.PointerEvent` undefined. Browser likely Chrome. Might implement generic handlers for pointer events and touch. Most automated drags generate pointer events. Could additionally listen to `mousedown`, etc., with a flag to dedupe: on pointerdown set lastPointerTime and ignore subsequent mousedown for 500ms? Or use pointer events, then `if (!window.PointerEvent)`. Simpler. Need avoid controls overlay capturing pointer.
- canvas covers viewport with `touch-action:none`.
- `pointerdown`: setPointerCapture, dragging=true, prev grid coords; add a splat at point with small force zero / dye.
- `pointermove`: if dragging, x/y from client; call `injectStroke(prev, current, color)`.
- `pointerup/cancel`: dragging=false; maybe add final splat; release capture.
- If pointer leaves canvas, capture ensures events.
- If pause: queue injection and apply to arrays immediately? Could apply splats directly on pointer event rather than queue? Need avoid simulation concurrency (single-thread JS; fine), but if pointer events between frames, writing arrays directly safe. But need handle active simulation step and queues? JS event loop serial. Direct injection into arrays is simpler and works even paused. However multiple segment splats with loops over radius ~150 cells each * maybe 100 segments =15k operations per event, fine. Need apply velocity boundary afterward? We can call setVelocityBoundary at end or next frame. If paused, render immediately. Need dye visible even paused.
- For every pointermove, line segment injection. Use queue maybe no need. Direct writing to velocity/dye arrays means `step` sees changes. Need clear can zero arrays. Fine.
- Need clamp injection loops to grid, no out of bounds.
- Use variable arrays with closure; on resize we'd need rebuild and possibly reset simulation; debounce resize. Could preserve old field by resampling? Not necessary; resizing clears and reseeds perhaps surprising. Requirement not mention. We can rebuild and seed initial scene on resize; but Clear should stay cleared. Need track `hasSeeded` / `cleared` and if user clears then resize should remain clear. We can resample dye and velocity from old arrays via bilinear, or simply reset to blank after resize (not ideal). Could implement

resample fields to preserve. But complexity manageable. Or set sim resolution fixed based on initial window at startup and simply map pointer to fixed grid; canvas draw stretched to viewport. If viewport resize, grid aspect not exact; mild distortion until reload. Bound resolution still. Could rebuild on resize and preserve via sampling. Let's do robust resample.

Maybe use WebGL for rendering only? no need.

Need define `Field` arrays as `Float32Array(N)` and helper `sample(field,x,y)`. On resize, create new arrays, sample old fields normalized coords, perhaps multiply velocities by newW/oldW etc to preserve physical speed. But simpler and optional. Need handle UI status. Use `ResizeObserver` or window resize. Debounce to avoid heavy realloc. canvas physical size based on CSS viewport and devicePixelRatio capped at 2 maybe. Main canvas backing store at CSS pixels * min(dpr,1.5); drawing low-res upscaled. At 1200x800 and dpr=1, fine. Need simulate with full-screen canvas. On high dpr maybe 1800x1200, still okay rendering drawImage. Cap at 1.5. Or set canvas.width=innerWidth, height=innerHeight (CSS pixels) regardless dpr; simpler and avoids cost. CSS width/height 100vw/vh. Since low-res dye upscaled, no need high dpi. Use main canvas backing size equal CSS size; crisp enough. We can use `ctx.drawImage(off,0,0,w,h)`. background built into offscreen pixels. Need set `imageSmoothingQuality='high'` maybe more expensive but still fine. At 1200x800 one draw. Could add a second screen glow with CSS? Perhaps use main ctx filter blur once at low res: draw offscreen to a separate glow canvas with CSS? We can create offscreen canvas same as main? Another drawImage of low-res at 1/3 size then upscale with smoothing gives blur naturally. E.g. `glowCanvas.width = W; height=H` no blur. Could draw low-res at 1/4 to `glow` then upscale; not necessary. Elegant enough with smooth interpolation. Use tone mapping and slight bloom via CSS `filter: drop-shadow`? That might apply to entire canvas and be expensive. Skip.

Need perhaps use `requestAnimationFrame` loop with capped steps:
let last = performance.now(), accumulator=0, running=true;
function frame(now) {
  

const elapsed=Math.min(50, now-last); last=now;
  if(running) {
    accumulator += elapsed;
    let steps=0;
    while(accumulator>=16.666 && steps<2){ step(); accumulator-=16.666; steps++; }
    if(steps===2) accumulator=0;
  } else accumulator=0;
  render();
  update stats every 250ms maybe.
  requestAnimationFrame(frame);
}
Need fixed dt=1. We can inject splats at pointer event rate independent of frame; okay. If tab throttles, cap steps. Simulation speed at low FPS may slow but controls responsive.
- Could instead step once per frame with dt=clamp(elapsed/16.7,0.5,1.5), but pressure and advection with varying dt. Fixed step simpler.

Need vorticity confinement details. Let's derive with arrays and avoid extra array maybe `curl = Float32Array(N)` plus `absCurl` can compute abs on fly. For each interior cell:
omega = 0.5*((v[i+1]-v[i-1]) - (u[i+W]-u[i-W]));
curl[i]=omega.
Second loop:
nx = 0.5*(abs(curl[i+1])-abs(curl[i-1]));
ny = 0.5*(abs(curl[i+W])-abs(curl[i-W]));
len=sqrt(nx²+ny²)+1e-5; nx/=len; ny/=len;
omega=curl[i];
u[i] += ny * omega * eps * dt; v[i] -= nx * omega * eps * dt;
Which sign yields amplification? Standard from GPU Gems:
N = ∇|ω| / |∇|ω||
force = ε (N × ω) in 2D: N=(Nx,Ny,0), ω=(0,0,ω), N×ω=(Ny*ω, -Nx*ω,0). yes as above. Good. eps maybe 0.18. Need avoid blowup clamp. Add before projection. Initial vortices maintain. Good.

Need boundary conditions for curl perhaps set copy; no need second loop boundaries.

Dissipation:
`const VEL_DECAY = 0.997; const DYE_DECAY=0.9985`. In advection multiply. For vorticity confinement force may sustain enough but velocity decay eventually zero. Pressure projection can reduce energy; fine.

Pressure iterates maybe 16. Need perhaps use Gauss-Seidel in-place for faster convergence than Jacobi; loops can update p using neighboring values already updated, with red-black? In-place is fine:
for k=0..15:
 for y=1..H-2:
  for x=1..W-2:
    p[i]=(p[i-1]+p[i+1]+p[i-W]+p[i+W]-div[i])*0.25;
 setPressureBoundary(p)
This is Gauss-Seidel and converges faster; no pTmp needed. Need ensure p reset to zero each step. 12-16 iterations. At boundaries p copy. This is numerically stable. Use 14 iterations at 14k = 196k. Good.
Projection:
compute div with u/v after boundary. p.fill(0); iterate; subtract gradients; set vel boundary.
Need maybe use over-relaxation? no.

Advection of velocity with self-advection uses source arrays `u0.set(u); v0.set(v); advectVelocity()`. Dye uses r0.set(r) etc. Need `advect(dst,src,u,v,decay,type)` with boundary handling. Could write specialized `advectScalar` and `advectVelocity` to avoid a `kind` branch per cell. We can write common `sample` with clamping. Avoid function call per cell for performance maybe inline bilinear. Need write code carefully.

Pseudo:

let W,H,N, u,v,u0,v0,r,g,b,r0,g0,b0,p,div,curl;
function alloc(w,h) {
 ...
}
function boundaryScalar(a) {
 for x=0..W-1: a[x]=a[x+W]; a[x+(H-1)*W]=a[x+(H-2)*W];
 for y=0..H-1: a[y*W]=a[y*W+1]; a[y*W+W-1]=a[y*W+W-2];
}
function boundaryPressure(a) same.
function boundaryVelocity(u,v) {
 for y=0..H-1:
  let row=y*W;
  u[row] = -u[row+1]; v[row]=v[row+1];
  u[row+W-1]=-u[row+W-2]; v[row+W-1]=v[row+W-2];
 for x=0..W-1:
  v[x]=-v[W+x]; u[x]=u[W+x];
  v[(H-1)*W+x]=-v[(H-2)*W+x];

u[(H-1)*W+x]=u[(H-2)*W+x];
 corners averages
}
Note order: applying left/right first then top/bottom overwrites corner u values, okay; set corners afterward.

advectScalar(dst,src,u,v,decay):
for y=1..H-2:
 row=y*W
 for x=1..W-2:
  i=row+x;
  px=x-u[i]; py=y-v[i]; // dt=1
  clamp px [0.5,W-1.5] maybe use `if(px<.5)px=.5; else if(px>W-1.5)...`.
  x0=px|0; y0=py|0; sx=px-x0; sy=py-y0;
  i00=x0+y0*W etc.
  dst[i]=(src[i00]*(1-sx)+src[i00+1]*sx)*(1-sy)+...*decay;
boundaryScalar(dst)

Could clamp px to [0,W-1.001]? x0 floor, x1 <=W-1. If clamp to W-1.5 then x0=W-2,x1=W-1. Good. If W small >2. Same y.

advectVelocity: call advectScalar(u,u0,u0,v0,velDecay), then advectScalar(v,v0,u0,v0,velDecay), then boundaryVelocity. But the generic boundaryScalar would set u left/right to copy, not reflect, and then second call likewise; after both call boundaryVelocity corrects. Fine.
Dye: copy r/g/b to r0 etc; advectScalar(r,r0,u,v,dyeDecay) etc.

Potential issue pressure divergence of Gaussian force injection: direct injection not divergence-free; projection removes divergence, leaving vortex pairs. Good.
Potential issue simulation on pointer injection while paused: boundary conditions not applied until step; render still shows dye. `injectStroke` can call `applyVelocityBoundary()` at end. Fine.

Splat:
function splat(cx,cy,forceX,forceY,color,intensity, radius) {
 const rad=radius || 6;
 const r2=rad*rad;
 const x0=Math.max(1,Math.floor(cx-rad)), x1=Math.min(W-2,Math.ceil(cx+rad)); similarly y.
 for y...
  d2=(x-cx)^2+(y-cy)^2; weight=Math.exp(-

d2/(r2*0.45)); maybe radius as e-fold.
  u[i] += forceX*weight; v[i]+=forceY*weight;
  r[i] += color.r*intensity*weight; ...
 clamp velocity ±8 and dye max maybe 4 to avoid runaway. Need `Math.exp` per cell per splat can be expensive if many splats. Could precompute a 2D kernel? But radius dynamic fixed. Use quadratic falloff `w = 1 - d2/r2; w*=w`; no exp. Smooth and cheap. At cells within radius. Good.
 `if(d2<r2){ w=1-d2/r2; w=w*w; ... }`.
- radius maybe 6.5 cells.
- forceX etc from drag direction. For line injection, define total dx,dy in grid units; length. stepCount=Math.max(1, Math.ceil(length/2.0)); stepSize=1/steps. For each j=1..steps:
  x=fromX+dx*j/steps...
  // per-splat directional impulse proportional to dx/length not dx/steps, so field strength independent of stroke speed/event granularity
  force = 2.0 maybe times min(length/??)
  vx = dx / length * push (constant)
  dye intensity = 0.14 maybe.
But if a slow tiny movement (length 0.2) yields step=1 and constant push, repeated pointermove events at 60Hz create huge velocity. Need scale force by movement length with cap. Perhaps use `speed = length * 0.75` (grid cells per event). If event corresponds 2 cells at 60Hz, force 1.5. If tiny 0.2, force .15. For a long drag with few events, length e.g. 100 cells, force 75 too high; clamp to e.g. 4.0. So `push = Math.min(4.5, Math.max(0.15, length*0.9));` direction unit vector. But each splat adds same force across full stroke; an event from x=0 to x=100 with 50 splats would create uniform velocity field along entire path, which is fine; local velocity about overlap*push ~20, clamp to 8. Could reduce per-splat force by overlap density maybe `/sqrt(steps)`? But dye similarly. We want strong swirls. Direct pointer `drag`

tool likely one pointermove from start to end, so a 600px stroke ~80 grid cells; step 40; with force 4.5 each splash overlapping radius => clamp 8, huge uniform velocity strip. That's okay maybe but can cause dye shoot to walls quickly. Could use `forcePerSplat = direction * min(3, length/steps * 0.8)` where `length/steps ≈2 cells` for step spacing 2. Then force ~1.6. Overlaps ~6 -> ~9 clamp 8. Fine. For tiny event length 0.5, steps=1, force .4. Good. So `const stepLen = length/steps; const push = Math.min(2.2, stepLen * 0.85);` maybe clamp. Dye `intensity = Math.min(0.28, 0.09 + stepLen*0.035)` ~0.16. Overlap ~6 -> ~1.0 concentration. Great.
- add dye color multiplied by 0.18. Need colors maybe cyan [0.15,0.85,1.0], magenta [1,0.2,0.65], etc.
- force uses dx/length and dy/length, plus maybe a small perpendicular alternating component to generate swirls? Injection + projection naturally creates vortices at stroke edges. A straight uniform strip of horizontal momentum after projection creates dipole and rolls into vortices. Could add slight alternating perpendicular force or curl seed. Perhaps not needed. Could add `splat` with forceX/forceY plus swirl term around center:
  u += (-dyLocal/radius)*curlStrength*w, v+=(dxLocal/radius)*curlStrength*w with sign alternating based on stroke; this creates eddies. But might be too contrived. Stable fluid + projection is sufficient.

Need ensure dye follows drag after release and responds to second drag in another direction. Could use injection of both momentum and dye along line. Pressure projection immediately makes dye near line advect. Second drag in other direction adds new field and changes existing dye movement. Good.

Initial seed should perhaps use the same `splat` with a vortex field rather than all dye blobs. Implement `seed()`:
clear arrays;
const colors=[
 {x:.34,y:.52,c:[.0,.8,1], spin:1, radius?},
 etc.
] 
for each:
 cx=W*..., cy=H*...
 rad=Math.min(W,H)*0.

12;
 for cells within rad*2? add tangential velocity:
  dx=x-cx,dy=y-cy,d2...
  w=Math.exp(-d2/(2*sigma²)) maybe using Math.exp on ~thousands once fine.
  speed=spin*3.2 * (Math.sqrt(d2)/sigma) * exp(-d2/(2sigma²))? A Rankine-ish vortex profile. This gives zero at center, max around sigma. Use `f = exp(-d2/(2*sigma*sigma))*spin*2.8/sigma`, u += -dy*f; v += dx*f. At d=sigma, speed=2.8*exp(-.5)=1.7 cells/tick -> 14px/frame maybe too fast. Use spin*2.2/sigma. Good.
 dye splats at 2-3 positions offset:
  splat(cx,cy, 0,0, color, .45, sigma*0.8)
  splat(cx+sigma*.55, cy-sigma*.2,0,0,color,.3,sigma*.55)
But `splat` force zero still loops. Fine.
Could add a broad central shear field to make blobs interact:
for all interior: u += 0.4*Math.sin(y/H*2π), v += 0.2*Math.sin(x/W*2π). But maybe not needed.
Then `boundaryVelocity`, `project`, render. Need pressure projection after initial vortex so divergence-free. Since vortices alone divergence-free. But pressure solve perhaps fine.
Maybe seed colors cyan, magenta, amber; create three small blobs (about 8-12 cells radius) across center. That's a "small amount". Use 3 vortex centers with radii 12-16 cells at W=144,H=96. Dye radius 6-8 cells. Good.

Need UI:
- full-screen body background #05070d; canvas fixed inset 0, width:100%;height:100%; display:block; cursor:crosshair.
- overlay panel top-left perhaps with backdrop blur, border, dark translucent. Heading "Fluid Dye" and subtitle; controls row:
  - color input styled square, plus swatches (5 buttons). Need define accessible labels.
  - Pause button with aria-pressed? text toggles "Pause"/"Resume" perhaps requirement. Use button id=toggle with "Pause".
  - Clear button.
  - maybe keyboard shortcuts info

(space pause, C clear). Nice but not required. Add legend/hint bottom-left maybe "Drag to stir • Space to pause • C to clear". Need ensure no network.
- status indicator with dot running/paused and sim resolution, maybe top right. Could use stats text. This helps verification.
- Need perhaps visual color selection: swatches with data-color and active outline; custom color input. Clicking swatch sets `selectedColor` and updates input. Could include color input labelled "Ink color". Use native `input[type=color]`; on input set color and active swatch none. Need parse hex.
- keyboard: `Space` toggles unless focus in input / button? prevent default. `c`/`C` clears.
- on Clear, zero arrays and maybe `hasFlow=false`, set running true? Need consider. Do:
function clearAll() { zero arrays; hasSeed=false; if(!running) toggleRun(); requestRender(); }
function toggleRun(){ running=!running; ... }
To avoid toggleRun side effects? set `running=true; btn.textContent='Pause'; status...`. This guarantees fresh flow. Maybe user expects clear not unpause, but requirement next drag can start a new flow so reasonable. Could mention "Clear also resumes" maybe not needed.
- On reseed via window resize: preserve flow if `everCleared?` Need simpler: resample existing fields; if blank remains blank. This avoids reseeding unexpectedly.
- `clearAll` zeros p/div/curl too.
- `resetSeed` initial.

Need diagnostics for browser verification:
- perhaps update `document.body.dataset.state` with running/clear and metrics every 200ms, e.g. `data-dye`, `data-speed`, `data-sim`. But inspect might not show body attributes? likely yes. Could add hidden `<pre id="diagnostics" aria-hidden="true">` with text maybe visible to DOM inspect. But we can make a small HUD showing "Flow 0.00 • Ink 0.00" which is user-friendly and useful. Could update text. Might be overkill but okay.
- Could expose `window.fluidDebug = { snapshot, injectStroke, clear, pause, ... }` for browser console; but no evaluate tool. Maybe `inspect` can execute? Need see tool docs? We can call `browser inspect` after create. It likely returns DOM and console messages. Could use JS to log metrics to console every second, then inspect output may

include console. But repetitive console logs might be noisy. We can log important state transitions (clear, pause) and perhaps initial, with metrics. Could deliberately set `window.__FLUID_TEST__` with methods and call through `key`? No evaluate. Could use URL query to trigger automated self-test maybe browser tool doesn't let navigate arbitrary URL? reload perhaps uses index.html with existing query? Could create query string? Not needed.
- Need verify via drag and screenshot / motion. Could call browser action drag with coordinates; then screenshot, motion. Need maybe inspect/collect DOM. Let's first create a prototype and run.

Potential challenge: browser environment may not provide GPU or support `OffscreenCanvas`; use `document.createElement('canvas')` for low-res buffer. Good.
- `ImageData` created once per allocation; use `new ImageData(W,H)` supported. Or `offCtx.createImageData(W,H)`.
- `render()` fill pixel data:
const data=image.data;
for i=0,j=0; i<N; i++,j+=4 {
  const rr=r[i], gg=g[i], bb=b[i];
  // tone map:
  data[j] = 4 + 255*(1-Math.exp(-rr*1.25));
...
  data[j+3]=255;
}
offCtx.putImageData(image,0,0);
ctx.clearRect; ctx.drawImage(off,0,0,canvas.width,canvas.height);
Need maybe use `ctx.fillStyle='#04070e'` first but offscreen opaque already.
- Add slight blue base using constants [5,8,16], plus colorful dye. Need ensure black levels. `1 - exp(-channel*1.2)`; dye concentrations ~1 => ~0.7=179. Good.
- Could add background subtle radial gradient via CSS on body but canvas opaque covers it. Could draw a precomputed background pattern to main canvas before draw? Offscreen pixels can include base gradient based on x,y; compute per cell:
  const nx=x/W-.5,ny=y/H-.5; vignette=...; baseR=4+6*vignette etc. But fill every frame with constant base plus maybe slight center glow. Precompute `bgR,bgG,bgB` Uint8 arrays once. Then base. Nice.
- To make dye glow, maybe use `ctx.globalCompositeOperation='lighter'` and draw offscreen twice: first normal, then `ctx.filter='blur(12px)'`

with alpha .18. But filter on full canvas potentially expensive. Can use offscreen at half sim resolution: set `glowCanvas.width=W/2`, draw offscreen into it, then draw glowCanvas scaled to display with `imageSmoothingEnabled=true` and globalAlpha .18, composite 'screen'. Since downsampling/upscaling gives a soft blur. Need create glow canvas W/2,H/2 and each render:
offCtx.putImageData
mainCtx.globalCompositeOperation='source-over'; draw offscreen to full
glowCtx.clearRect; glowCtx.drawImage(off,0,0,glow.width,glow.height);
mainCtx.globalCompositeOperation='screen'; mainCtx.globalAlpha=.22; drawImage(glow,0,0,canvas.width,canvas.height); reset.
This gives halo from bilinear interpolation only mild. Could apply `glowCtx.filter='blur(2px)'` on low-res (e.g. 72x48) cheap. `ctx.filter` support likely. But no need; smooth upscaling gives glow-like soft. Drawing low-res twice with screen can brighten. Fine.
- Another idea draw offscreen with `ctx.filter='saturate(1.2)'` but maybe not.
- Need careful `canvas.width` may be 0 if initial before layout; use window.innerWidth etc.

Grid resizing:
`let cleared = false; let didSeed = false;`
function configure(keep=true) {
 const old={W,H,u,v,r,g,b,...} if arrays exist.
 const cw=Math.max(320,window.innerWidth), ch=Math.max(240,window.innerHeight);
 canvas.width=Math.round(cw); canvas.height=Math.round(ch);
 const targetCells=17000;
 let cell=Math.sqrt((cw*ch)/targetCells); cell=Math.max(5.8,cell);
 let newW=Math.min(180,Math.max(80,Math.round(cw/cell)));
 let newH=Math.min(120,Math.max(55,Math.round(ch/cell)));
 // at 1200x800 cell=7.52? sqrt(960k/17000)=7.515, W=160,H=106. N=16960.
 allocate(new W,H); create buffers.
 if(keep && old.W) resample each field.
 else seedInitial();
 render();
}
Need ensure W/H integer and aspect. At 1200x800 W=160,H=106;

16,960. Pressure iterations 12 maybe ~200k. Good.
- If viewport 1200x800 browser tool likely exact. Work per frame ~5 fields advect (85k cells) + curl (17k) + pressure 14*17k=238k + render 17k. Maybe 400k operations plus drawImage, should be okay.
- Use 10 pressure iterations? Incompressibility quality with Gauss-Seidel: 12 enough. Use 14. Could adapt based on N: `PRESSURE_ITERS=12` to bound. Vortices still. Let's choose 14. At 17k ~238k. Fine.
- Need perhaps optimize `Math.exp` in render; 3 exps per pixel 17k*3=51k per frame, costly. Use rational tone mapping `t = c/(1+c)` or `1 - 1/(1+c)`: 2 multiplications, no exp. `channel = base + 255 * c/(1+c*0.8?)`; for c=1, .556 ->142. Use `c*1.4/(1+c*1.4)` = .583 for c=1. Could use `1 - 1/(1+c*1.5)` same. Avoid exp. Use:
let tr = rr*1.45; data[j]=bgR[i]+(255-bgR[i])*(tr/(1+tr));
This gives 151 for c=1. Bright enough. Could include saturation boost by `max = Math.max(rr,gg,bb)`? no.
- Since colors mix, values. Clamp dye to max 4 to avoid Infinity.
- Need `Float32Array` values; loops use local aliases for speed.

Pressure/diffusion stability: Need understand initial force and projection scaling. Let's test perhaps with Node headless simulation by extracting JS? Could perhaps run browser and use screenshots. But to catch bugs, we can write a Node script replicating core? Could use jsdom? no. Use browser to run and inspect screenshots. We can also use browser `inspect` maybe evaluate window? Need see. Let's generate file with code, then browser reload and inspect. Need potentially use debug logs at start and after clear? Could add console.info("Fluid ready ...") to ensure no errors. No intentional errors. Browser inspect will show console errors if any.

Need perhaps `window.__fluid` debug API that could be used via a custom `

key` sequence? Maybe add URL hash auto-test and use browser reload with query? Browser tool reload likely just reloads current URL, no query parameter setting. Could click a hidden self-test button? Not necessary; we can use drag/screenshot/motion.

Let's write full file. Need carefully ensure no syntax errors. Could use Node to extract script and syntax-check with `node --check`, but script has DOM references; syntax check only okay. We can write JS into temp file for check, perhaps use Python regex. We'll do.

Let's outline HTML:

<!doctype html>
<html lang=en>
<head>
<meta charset=utf-8>
<meta name=viewport content="width=device-width,initial-scale=1,maximum-scale=1,user-scalable=no">
<title>Fluid Dye</title>
<style> ... </style>
</head>
<body>
<canvas id=fluidCanvas aria-label=...></canvas>
<div class=grain maybe pointer-events none via CSS radial gradients? Canvas opaque, overlay can add subtle vignette:
<div class=vignette></div> with background radial-gradient transparent -> dark; pointer-events:none.
<header class=panel> ...
  <div class=title-row><span class=badge>...</span>...
  <div class=controls>
    <div class=color-group>
      <label for=ink>Ink</label>
      <input type=color id=ink value="#38d9ff">
      <div class=swatches role=group aria-label=...>
        <button ... style="--c:#38d9ff" data-color... class=active></button>
...
    <button id=pauseBtn class=action>Pause</button>
    <button id=clearBtn...>Clear</button>
  </div>
  <div class=readout><span id=stateDot></span><span id=stateText>Running</span><span class=sep>•</span><span id=gridInfo>...</span><span ...><span id=flowInfo>...</span></div>
</header>
<div class=hint>Drag anywhere ...</div>
<script> ... </script>
</body></html>

Need overlay maybe panel width 340. At 1200x800, top-left. Canvas gets pointer events; `.vignette` pointer-events:none; panel pointer events auto; hint none. Need controls responsive on narrow viewport: flex-wrap, panel max width etc.

CSS:
html,body { margin:0;width:100%;height:100%;

overflow:hidden;background:#05070e;color:#eaf2ff;font-family:ui-sans-serif,system-ui,...}
#fluidCanvas { position:fixed;inset:0;width:100vw;height:100vh;display:block;touch-action:none;cursor:crosshair; }
.vignette { position:fixed;inset:0;pointer-events:none; background: radial-gradient(circle at 50% 45%, transparent 30%, rgba(0,0,0,.15) 72%, rgba(0,0,0,.5) 100%); mix-blend-mode:multiply? If on top, multiply darkens dye edges. `box-shadow: inset 0 0 140px rgba(0,0,0,.55)`.
.panel { position:fixed;top:20px;left:20px; z-index:2; width:min(360px,calc(100vw - 40px)); padding:16px; border:1px solid rgba(...); border-radius:18px; background:rgba(8,13,25,.72); backdrop-filter:blur(14px); box-shadow...}
Maybe `backdrop-filter` is fine no external.
button etc.
input[type=color] width 38 height 34 border 0 etc; appearance none? Need style:
input[type=color]{ width:38px;height:34px;padding:0;border:1px solid...;background:none;border-radius:9px;cursor:pointer}
::-webkit-color-swatch etc.
swatches button 22x22 border-radius 50%; border 2px solid transparent; box-shadow 0 0 0 1px rgba...; background:var(--c); active outline.
action button etc.
readout small.
hint position bottom center.
Could add `.panel h1` with letter spacing etc.

Need event handling with panel:
- Canvas sits behind; panel intercepts only panel area.
- On pointerdown on canvas only; use canvas.addEventListener.
- `pointermove` on canvas with capture. Need call `e.preventDefault()`.
- pointerup loss: add `lostpointercapture`, `pointercancel`.
- Could support mouse fallback if PointerEvent absent:
if(window.PointerEvent){ pointer events } else { mouse/touch events }.
- Need perhaps browser tool `drag` may dispatch only mouse events and not pointer events? In modern Chrome, a synthetic `MouseEvent` via CDP `Input.dispatchMouseEvent` produces pointer events

as well. likely. But to be safe, implement mouse handlers with dedupe:
  let lastPointerEvent=0;
  pointerdown handler sets `usingPointer=true`.
  mousedown handler: if (performance.now()-lastPointerEvent<100) return; else start.
  mousemove: if `usingPointer` and recent pointer events, return.
But if both generated for same action, pointerdown then mousedown shortly after; skip. Need maintain `pointerMode` until pointerup. For browsers supporting pointer events, pointer events sufficient. For synthetic automation that somehow only sends mouse events, fallback works.
Better unified `startStroke(x,y,id,type)`, `moveStroke`, `endStroke`. For pointer events, call; for mouse events if no active pointer. Could attach both and dedupe via `activeSource`:
let activeSource=null;
function begin(source,x,y){ if(activeSource) return; activeSource=source; ...}
function move(source,x,y){ if(activeSource!==source) return; ...}
function end(source){ if(activeSource!==source) return; activeSource=null; ...}
If pointer events generated first, activeSource='pointer'; mouse events ignored until pointerup. If pointerup fired before mousedown, then mousedown may call begin again and add an extra zero-force dye splat. Could set `ignoreMouseUntil=performance.now()+150` on pointerup; mouse handler checks. Or attach mouse fallback only if `!window.PointerEvent`. Since browser likely modern. Simpler with fallback conditional. Need touch events fallback too maybe not needed. Let's implement PointerEvent and non-pointer mouse/touch fallback. Could also attach a `mousemove` listener on window in pointer mode? pointer capture handles.

Potential issue `setPointerCapture` on canvas: okay.
- Need convert client coords:
const rect=canvas.getBoundingClientRect(); gx=(clientX-rect.left)/rect.width*(W-1); gy=...*(H-1); clamp to [1,W-2].
- Since canvas fixed full screen, simply x = clientX/innerWidth*(W-1), but rect robust.
- On pointerdown, add `splat` with zero velocity and dye intensity .55 radius 5 maybe. Need color.
- On pointermove, `injectStroke(prev,cur)`:
const dx=...,dy=...,len=Math.hypot...
if len<0.02 return.
const steps=Math.min(160, Math.max(1,Math.ceil(len/

1.8))); // max work
const stepLen=len/steps; // if len huge cap steps? at 160 and len>288, stepLen>1.8. fine.
const push=Math.min(2.4,Math.max(.12, stepLen*0.9)); // velocity per splat
const dyeAmount=Math.min(.32, .10+stepLen*.035)
const ux=dx/len,uy=dy/len
for s=1..steps:
 x=x0+dx*s/steps...
 splat(x,y, ux*push, uy*push, color, dyeAmount, 6.0)
Maybe for long line, every 1.8 cells and radius 6 => ~6 overlapping splats, max push 2.16 each => 13; clamp velocity to 8. Fine.
Could use `splat` add curl with sign:
const swirl = Math.min(.9, push*.35) * ( (s%2)?1:-1 )? Alternating pattern could create noise. no.
- On pointerup, call maybe no extra.
- If paused, direct injection still visible; `render()` called immediately after stroke (but next RAF anyway). Set `needsRender=true`.
- Need ensure velocity boundary after injection: call boundaryVelocity at end of `injectStroke`, but pressure projection only next running step. Fine.
- Need update diagnostics.

Clear:
`function clearAll({resume=true}={}) { for arr of fields arr.fill(0); if (resume) setRunning(true); render(); updateReadout(true); }`
Need `hasInk` metrics from arrays. `metrics()` loops all N maybe every 250ms; fine. Compute `sumDye=max?`, `maxSpeed`. Use for `data-*` and readout. Could avoid user-visible flow numbers? Show `Flow 0.00 · Dye 0.00`. Could update every 250ms. Need maybe metrics highlight status. Use `flowEl.textContent = ...`.
`document.body.dataset.ink = avgDye.toFixed(3); dataset.flow=...; dataset.running=...; dataset.grid=...;` This might be used by inspect.
- `console.info` on startup? Could log only once. Need ensure no errors. We can set `window.fluidApp` with functions and state for external testing:
```
window.fluidApp = {
  clear: () => clearAll(false), pause:..., resume:...
,
  metrics: getMetrics,
  inject: (x1,y1,x2,y2,hex) => {...}, // coords CSS px?
  setColor:...
};
```
This is useful if browser `inspect` supports eval? It won't call, but perhaps no harm. Could also use a keyboard shortcut "t" to run a self-test injection; not needed. But maybe for our verification we can automate by triggering with `key` events if we add keyboard shortcuts. E.g. pressing `1`/`2` triggers test strokes? That would be hidden weird behavior. Better not.
- Could use `window.fluidApp.inject(x1,y1,x2,y2,hex)` via console? Browser tool doesn't evaluate. But `key` perhaps type into something? no.
- We can rely on drag.

Need perhaps include visual debug overlay of velocity field? Not required. Could have a tiny toggle? no.

Need numerical correctness. Let's derive projection loops and boundaries in more detail.

`computeDivergence()`:
for y=1..H-2, x=1..W-2:
 div[i]=0.5*((u[i+1]-u[i-1])+(v[i+W]-v[i-W]));
 p[i]=0; // p.fill(0) already
Set pressure boundary? p boundary zero initially; set after each iteration.
for k=0;k<14;k++:
 for y...
   p[i]=(p[i-1]+p[i+1]+p[i-W]+p[i+W]-div[i])*0.25;
 boundaryScalar(p);
Then:
for y...
 u[i] -= 0.5*(p[i+1]-p[i-1]);
 v[i] -= 0.5*(p[i+W]-p[i-W]);
boundaryVelocity(u,v)
Does this work at boundaries? We don't alter boundary velocities during subtraction but then boundaryVelocity sets them based on interior. Good.
- For in-place Gauss-Seidel, p boundary set to nearest interior (Neumann). Good.
- Need maybe `div` boundary set? no.

`vorticityConfinement()`:
calculate curl interior; set boundaryScalar(curl). Then second loop:
const nx=0.5*(abs(curl[i+1])-abs(curl[i-1]));
const ny=0.5*(abs(curl[i+W])-abs(curl[i-W]));
const l=Math.hypot(nx,ny)+1e-5;
u[i]+=ny/l*curl

[i]*EPS;
v[i]-=nx/l*curl[i]*EPS;
Could use `Math.sqrt` instead of hypot for speed. EPS=0.17. Need cap velocities:
`if (u[i]>8) u[i]=8; ...` maybe apply after injection and project? Injections clamp. Confinement might slowly increase but decay. Could clamp in vorticity loop or global `clampVelocity()` after step. Use clamp in `splat` and perhaps after projection loop:
```
let su=u[i]-...
if(su>MAX)u[i]=MAX...
```
Need maintain stable. Implement `clampVelocity()` separate loops over N maybe cost small. Call after injection maybe splat already clamps each affected cell; after vortic confinement and projection might remain under 8 due to pressure gradients potentially >8. Could call after projection to clamp all. One extra 17k loop. Fine.
- `MAX_SPEED=7` cells/tick. At 7.5 px/cell, 52 px/frame; could be fast but okay. Maybe 5.5 cells/tick, 41 px/frame. Strong swirls. Use 6.0.
- Drag push 2.4 * overlap => saturates at 6. Good.
- Initial vortex speeds ~2.2. Fine.

`step()`:
```
function step(){
 applyVorticity();
 project(); // makes compressed force divergence-free
 u0.set(u); v0.set(v);
 advectScalar(u,u0,u0,v0,VEL_DECAY);
 advectScalar(v,v0,u0,v0,VEL_DECAY);
 boundaryVelocity(u,v);
 project();
 r0.set(r); ...
 advectScalar(r,r0,u,v,DYE_DECAY); ...
 clampDye maybe generic clamps to 5;
}
```
Need project before self-advection, after applied forces/vorticity. Note projection modifies u,v, then u0/v0 set. Good.
- Could apply velocity decay via advectScalar. Dye decay likewise.
- Vorticity confinement uses curl from current u/v. Fine.
- `advectScalar` boundaryScalar for u and v will overwrite boundary; then boundaryVelocity corrects.
- Pressure p used as scratch. div/curl used.
- Dye field likely accumulates at boundaries due to scalar boundary copying; okay.

Initial seeding:
Need use `splat` for dye and `addVortex` for velocity. But `splat` clamps u/v; if force

zero, fine. Need colors in current arrays. `seedInitial()` after allocation:
```
const s=Math.min(W,H);
const seeds=[
 {x:.36,y:.50, c:hexToRgb('#22d3ee'), spin:1, r:.105*s},
 {x:.58,y:.43, c:'#ff4fa3', spin:-1, r:.12*s},
 {x:.50,y:.65, c:'#ffb347', spin:1, r:.09*s},
];
for each addVortex(...)
for each splat at center and offset ...
boundaryVelocity(); project(); render();
```
Could be too many blobs but still small. Need ensure UI panel at top-left doesn't cover seeds. Centers x .35*160=56 (420px), y .5*106=53 (400px); fine. Others center 744,344; 600,520. Nice.
- Add a gentle cross flow perhaps:
```
for interior:
 u[i]+=.18*Math.sin(y/H*Math.PI*2); v[i]+=.12*Math.sin(x/W*Math.PI*2)
```
This is divergence? ∂u/∂x=0, ∂v/∂y=0 so divergence-free. Nice. It gives slight global movement. But vortices enough.
- Dye blobs: one at each vortex center maybe rotating around itself remains blob (solid-body-ish) and doesn't visibly swirl; offset blobs will orbit. Add multiple small splats around circumference with varying hues. Could add:
for k=0..3:
 angle = ...
 splat(cx+cos*a*sigma*.75, cy+sin*a*sigma*.75, 0,0,c,.42,sigma*.38)
This creates spiral arms around vortex center. That's more visually fluid. But "small amount" perhaps okay. Use 2-3 splats per seed. Then over time they'll swirl.
- Need avoid dye values too high: intensity .55 and radius 5 => center ~.55, tone map ~112; visible but maybe faint. Use .9 center and .35 arms. Need initial scene visible. Dye tone mapping with c=.9 gives 144. Good. Use 1.0 at center. Drag dye amount .18 overlapping ~6 => ~1.1. Good.
- Colors from hex parse with gamma? Use normalized sRGB; fine.
- `splat` with color array values 0..1

and intensity. Need color selector default cyan #38d9ff -> [0.22,0.85,1]. Presets: cyan, coral, violet, lime, white maybe.
- Need handle color input value always hex. `hexToRgb` supports #rgb and #rrggbb.
- Swatch click update `selectedColor`, `inkInput.value=hex`, active classes, maybe custom color label. Add keyboard? buttons naturally.

Metrics:
```
function getMetrics(){
 let ink=0, speed=0, max=0;
 for(let i=0;i<N;i+=4?) ...
 return {ink:ink/N, speed:speed/N, max}
}
```
Sampling every 4th cell enough. dataset values. Need avoid using `for i+=4` where indexing fine.
`readout`: `flowEl.textContent = 'Flow ' + speed.toFixed(2) + ' · Ink ' + (ink*100).toFixed(1)` maybe.
Maybe use dynamic status dot color.
- `gridInfo.textContent = W+'×'+H+' grid';`
- `stateText.textContent = running?'Running':'Paused';`
- `pauseBtn.textContent = running?'Pause':'Resume'; pauseBtn.setAttribute('aria-label'...)`; body class paused.
- Need maybe if clear auto resumes, update label.

Render on pause: `step` not called; render still called each frame, wasting CPU but okay. Could skip render unless `needsRender` when paused; but simpler. Controls responsive. At 1200x800 render 17k pixels per frame maybe 1ms. Fine. Could optimize: if !running && !needsRender skip putImageData/draw, but no need.

Motion after release: browser motion tool likely captures frames; initial seed itself moves, so can detect. To verify drag and second drag visually via screenshots. Need perhaps pause/clear checks.

Need perhaps add a built-in "velocity field visualization" toggled by holding Alt? Not required and might complicate. Could sample flow after release by exposing debug metrics and screenshots. We can use visual screenshots after drag and after some time. Need maybe browser `motion` captures a sequence; we'll use.

Let's write the file. Need careful code with no external resources. Use IIFE `'use strict';`.

Let's draft full JS.

```
(() => {
 const canvas=...;
 const ctx=canvas.getContext('2d',{alpha:false});
 const off=document.createElement('canvas'); const offCtx=off.getContext

('2d',{alpha:false});
 const glow=...; glowCtx...
 const inkInput...
 let W=0,H=0,N=0;
 let u,v,u0,v0,r,g,b,r0,g0,b0,p,div,curl;
 let image, bgR,bgG,bgB;
 let running=true, accumulator=0,lastTime=performance.now(), lastStats=0, needsRender=true;
 let selectedColor=hexToRgb(inkInput.value);
 let activePointer=null, prevX=0,prevY=0;
 const ...
 function makeArray(){ return new Float32Array(N); }
 function allocate...
```
Need alpha:false with putImageData; offscreen context alpha:false may still accept ImageData alpha=255. Fine.
`glowCtx` with alpha:true.

`configure(keep)`:
```
function configure(preserve){
 const cssW=Math.max(320, window.innerWidth || document.documentElement.clientWidth);
 ...
 canvas.width=Math.round(cssW); canvas.height=Math.round(cssH);
 let cell=Math.sqrt(cssW*cssH/TARGET_CELLS);
 cell=Math.max(5.8,cell);
 const nw=Math.min(180,Math.max(80,Math.round(cssW/cell)));
 const nh=Math.min(120,Math.max(55,Math.round(cssH/cell)));
 const old = W ? {...arrays,W,H,N} : null;
 W=nw;H=nh;N=W*H;
 off.width=W; off.height=H; glow.width=Math.max(1,Math.floor(W/3));...
 image=offCtx.createImageData(W,H);
 arrays...
 bg arrays = new Uint8Array(N); fill using loops
 if(old&&preserve){resampleField...} else seedInitial();
 // Ensure ctx.imageSmoothing...
 update grid info; needsRender=true; render();
}
```
Need `canvas.width=cssW` maybe use Math.round; CSS width 100vw. If dpr ignored, okay. Could set canvas.style.width='100%',height etc via CSS.
- On resample, `resample(oldArray,oldW,oldH,newArray,newW,newH,velocityX?)`:
```
for y=0;y<H;y++:
 sy=(y+.5)/H*(oldH-1)
 ...
 for x:
   sx...
   val=bilinearOld
   new[i]=val
```
Need clamp sx [0,old

W-1.001], etc. Could use local `sampleOld`.
- For velocity scaling, new array values should scale by W/oldW etc; but if grid aspect changes, scale u by W/oldW, v by H/oldH maybe. Could pass scale. Simpler no scaling; small resizes only. Might preserve approximate movement. Good.
- Need avoid reseeding on resize after Clear: preserve blank arrays. Great.
- on initial configure(false), seed.
- Need if window resize while pointer active: activePointer=null perhaps.
- debounce resize:
```
let resizeTimer=0;
window.addEventListener('resize',()=>{ clearTimeout(...); resizeTimer=setTimeout(()=>configure(true),120);});
```
- Need maybe initial `configure(false); requestAnimationFrame(frame);`.

`seedInitial()`:
```
function seedInitial(){
 const s=Math.min(W,H);
 for each...
 addVortex...
 for each...
 addGentleField...
 boundaryVelocity(u,v);
 project();
}
```
Need `splat` uses `selectedColor`? pass color. It uses current arrays. Fine.
`addVortex(cx,cy,sigma,spin)`:
```
const reach=sigma*2.6, r2=reach*reach, sig2=sigma*sigma;
for y...:
 for x...:
   d2...
   if d2<r2:
      const w=Math.exp(-d2/(2*sig2));
      const swirl=spin*2.4*w/sigma;
      u[i]+=-dy*swirl;
      v[i]+=dx*swirl;
```
At dy=sigma, u=-spin*2.4*.606=-1.45. Good.
`for all cells`: u += 0.16*sin(2π*y/H); v +=0.12*sin(2π*x/W); maybe field divergence-free as noted. Good.
Dye:
```
for k=0;k<4;k++:
 angle=seed.phase + k*1.7
 dist=sigma*(.35+.15*k)
 splat(cx+cos*dist, cy+sin*dist,0,0,color,.75,Math.max(3,sigma*.45))
```
Plus central splat .6 radius sigma*.55. This may add lots of dye around ~3 vortex centers. Still small.
Maybe seed colors from hex. Use `hexToRgb`.
- Need call `clampVelocity()` after

seeding.

`splat`:
```
function splat(cx,cy,fx,fy,color,amount,radius){
 const rad=Math.max(1.5,radius), r2=rad*rad;
 let x0=Math.max(1,Math.floor(cx-rad)),...
 for ...
  const d2...
  if(d2<r2){
   let t=1-d2/r2;
   const w=t*t; // zero at edge
   const i=...
   let nu=u[i]+fx*w;
   ...
   u[i]=clamp(nu,-MAX,MAX)
   let nr=r[i]+color[0]*amount*w; ...
   r[i]=nr>4?4:nr;...
  }
 }
}
```
Potential issue with zero force and clamping velocity each splat harmless. Need maybe `Math.max(0, ...)` negative dye never.
- For color white, all channels. Fine.
- sliders none.

`injectStroke(x1,y1,x2,y2,color)`:
```
const dx=x2-x1...
if(len<.02)return;
const steps=Math.min(180,Math.max(1,Math.ceil(len/1.8)));
const stepLen=len/steps;
const push=Math.min(2.4,Math.max(.08,stepLen*.9));
const amount=Math.min(.34,.10+stepLen*.04);
const ux=dx/len, uy=dy/len;
for s=1; s<=steps;s++ ...
 boundaryVelocity(u,v);
 clamp...
 needsRender=true;
}
```
Need if paused: direct splats still injected; render immediate maybe via `render()` at end of pointermove? Could set needsRender and RAF will render. Fine. If pointer events high frequency, no need.
`pointerdown`: splat with 0,0, selectedColor, .65, 5.2; boundary.
`pointermove`: inject from prev to current. Use event.getCoalescedEvents? Could use to better capture path:
```
const events = typeof e.getCoalescedEvents==='function' ? e.getCoalescedEvents() : [e];
for(const ev of events) { const {x,y}=...; injectStroke(prevX,prevY,x,y,...); prev=...}
```
Need browser synthetic event might not have getCoalescedEvents; fallback. This can produce many strokes; our per-distance scaling handles.
- Need avoid multiple active pointers. `

activePointer` id. On pointerdown if activePointer!==null return; set activePointer=e.pointerId.
- `canvas.setPointerCapture(e.pointerId)` try/catch.
- On pointermove check `e.pointerId===activePointer`.
- On pointerup check. `endStroke`.
- `window.addEventListener('blur',...)`.
- For fallback:
```
if(!window.PointerEvent){
 canvas.addEventListener('mousedown',...)
 window.addEventListener('mousemove',...)
 window.addEventListener('mouseup',...)
 canvas.addEventListener('touchstart'...)
 ...
}
```
Could simplify with generic:
```
function start(clientX,clientY){...}
function move(clientX,clientY){...}
function end(){...}
```
Then pointer handlers call these; fallback uses them. Need event-specific `activePointer` separate. Let's define:
```
let drawing=false;
function beginStroke(clientX,clientY,id=null){
 if(drawing)return;
 drawing=true; activeId=id; ...
}
function continueStroke(clientX,clientY,id=null){
 if(!drawing||id!==activeId)return;
 ...
}
function finishStroke(id=null){ if(!drawing||id!==activeId)return; drawing=false; activeId=null; }
```
For pointer capture, move on canvas; fallback move on window.
- If pointer events and mouse events both attached unconditionally, need `pointerMode=!!window.PointerEvent`, so only attach fallback if no PointerEvent. Good.

`toGrid(clientX,clientY)`:
```
const rect=canvas.getBoundingClientRect();
return [clamp((clientX-rect.left)/rect.width*(W-1),1,W-2), ...]
```
Need clamp function.
- On pointerdown if on canvas, panel doesn't trigger.
- Need perhaps `pointer-events:none` on non-control child text? panel itself active; no issue.

`setRunning(value)`:
```
running=value; accumulator=0; pauseBtn.textContent=running?'Pause':'Resume'; pauseBtn.setAttribute('aria-pressed', String(!running)); state...; body.classList.toggle('paused',!running); needsRender=true; updateReadout();
```
`aria-pressed` on toggle perhaps true when paused? Could label `aria-label="Pause simulation"` etc. Fine.
- `toggleBtn.addEventListener('click',()=>setRunning(!running))`.
- `clearBtn.addEventListener('click',()=>{clearAll(); setRunning(true); log

maybe})`. Need order: clear then resume. `clearAll` could call setRunning internally with argument.
- keyboard:
```
window.addEventListener('keydown',e=>{
 const tag=e.target.tagName;
 if(e.code==='Space' && tag!=='INPUT' && tag!=='BUTTON'){...}
 else if(e.key.toLowerCase()==='c'&&!e.metaKey...){clear...}
});
```
If focus on button and space, browser triggers click; don't double toggle. Need restrict interactive tags. `if (e.target.closest('button, input')) return;` for space. For c, allow unless input.
- Maybe pause/resume text. Need clear auto resume.
- On color input: `selectedColor=hexToRgb(e.target.value); clear active swatches;`. On swatch click: set input.value; selectedColor; active.
- Need maybe label focus.

`clearAll()`:
```
const fields=[u,v,...]; for(const a of fields) if(a)a.fill(0);
needsRender=true;
setRunning(true);
updateReadout(true);
```
Need `setRunning` calls `updateReadout` which calls metrics on zero arrays. Good.
- Clear should reset velocity and dye, including boundary arrays all zero.
- Need clear active stroke? maybe `drawing=false`? If clear clicked while dragging, canvas pointerup not delivered maybe; set drawing=false. But clear button pointer event separate; fine. Could set.

`project()` uses p fill. Need `p.fill(0)` each call. boundaryScalar(p) after each iteration. Need ensure `p` boundary values update from interior; corners perhaps okay. Implement generic:
```
function setScalarEdges(a){
 for(let x=0;x<W;x++){a[x]=a[W+x]; a[(H-1)*W+x]=a[(H-2)*W+x];}
 for(let y=0;y<H;y++){...}
}
```
Order top/bottom first then left/right produces corners from top rows. Fine. Could do left/right first then top/bottom. Either. Need no issue.
`setVelocityEdges`:
```
for y:
 const row=y*W;
 u[row]=-u[row+1]; v[row]=v[row+1];
 u[row+W-1]=-u[row+W-2]; v[row+W-1]=v[row+W-2];
for x:
 const top=x,bottom=(H-1)*

W+x;
 v[top]=-v[W+x]; u[top]=u[W+x];
 v[bottom]=-v[(H-2)*W+x]; u[bottom]=u[(H-2)*W+x];
 corners:
 u[0]=0.5*(u[1]+u[W]); etc
```
Need be careful after top/bottom loop, at x=0, `u[W]` had been set maybe? Actually y=1 row left boundary from first loop, u[W]=-u[W+1]. Then top u[0]=u[W]=-u[1], but expected near corner diagonal no-slip maybe average. Fine. v[0]=-v[W], and v[W]=v[W+1], so v[0]=-v[W+1]. Corner could be average. Use corner averaging at end:
```
u[0]=0.5*(u[1]+u[W]); v[0]=0.5*(v[1]+v[W]); ...
```
Need u[W],v[W] set from first loop. Good.
- For boundary of pressure, copy interior.
- For dye, copy interior. If dye hits wall, it sticks/accumulates; okay.

`advectScalar` uses `uField` and `vField`, not necessarily current u/v. Need clamp backtraced coordinates to [0.5,W-1.5], [0.5,H-1.5]. Use local variables.
```
let x0=px|0; // px>=.5 => floor
let y0=py|0;
const sx=px-x0;
const a=x0+y0*W;
dst[i]=...
```
Need ensure x0+1 <= W-1, y0+1 <=H-1 due clamp max W-1.5 -> floor W-2, +1 W-1. Good.
- Source arrays may have boundary values set; yes.
- `decay` perhaps 0.9989.
- Need clamp dye max 5 in advect? Since only decay and interpolation, no increase above max; injection clamps. Fine.

`vorticityConfinement` needs compute curl at boundaries perhaps setScalarEdges(curl). Then second loop uses curl at interior and neighbors including boundary. Good.
- Need `curl` array values from previous step at boundaries; set edges.
- `EPS=0.14` maybe. Need

scale by step dt=1.
- After confinement, `setVelocityEdges(u,v)` maybe call in project next; project's divergence reads interior only, so okay.

`applyVorticity` standard sign. Let's test with a simple vortex to see if confinement amplifies or dampens. Suppose solid vortex with curl ω>0 uniform center, |ω| decreases outward. At point right of center (x>0), |ω| decreases with x => nx<0, ny=0. N≈(-1,0). force=(Ny*ω=0, -Nx*ω=+ω) => +y force. At right side of CCW vortex (ω positive), tangential velocity is +y. So amplifies. Good.
- At top, N=(0,-?) need sign etc fine.

`clampVelocity`:
```
for i=0;i<N;i++:
 if(u[i]>MAX)u[i]=MAX; else if(u[i]<-MAX)...
```
Call after project. Could have pressure gradient make velocities >MAX; clamp.
- `project()` called in seed and step; after it call clamp. Fine. Or inside project at end.

Need `updateReadout` cost. Use metrics loop stride 4:
```
let ink=0, speed=0, max=0, count=0;
for(i=0;i<N;i+=4){ ink+=r[i]+g[i]+b[i]; s=Math.sqrt(u[i]*u[i]+v[i]*v[i]); ...}
ink/=count*3 maybe; speed/=count;
flowInfo.textContent=`flow ${speed.toFixed(2)} · ink ${(ink*100).toFixed(0)}%`;
body.dataset.speed...; body.dataset.ink...
```
Maybe user-facing "Motion 0.00 · Dye 0%". Fine.
- Need dataset numeric string perhaps. `document.body.dataset.flow=speed.toFixed(3); ...`.
- `updateReadout` called every 250ms from frame and on events. Need body exists. yes.
- `stateText.textContent=running?'Running':'Paused'`.
- `statusDot` class via CSS based on body.paused.

`frame`:
```
function frame(now){
 const elapsed=Math.min(50,now-lastTime); lastTime=now;
 if(running){
  accumulator += elapsed;
  let steps=0;
  while(accumulator>=STEP_MS && steps<2){step(); accumulator-=STEP_MS; steps++; needsRender

=true;}
  if(steps===2) accumulator=0;
 } else {accumulator=0;}
 if(needsRender || running){
   render();
   needsRender=false;
 }
 if(now-lastStats>250){updateReadout(); lastStats=now;}
 requestAnimationFrame(frame);
}
```
If running, render every frame regardless. If paused and no needsRender, skip. Good.
- On clear, need immediately render; could call render() in clearAll rather than relying on frame. Fine.
- On resize configure calls render.
- On injection, needsRender=true; if paused frame renders. Good.

Need maybe `document.visibilitychange` to reset lastTime/accumulator; can handle with lastTime=performance.now.

`render()`:
```
if(!image)return;
const data=image.data, br=bgR...
for(let y=0,i=0,j=0;y<H;y++) for x...:
 const cr=r[i]*1.45; ...
 data[j]=br[i]+(255-br[i])*(cr/(1+cr)); // output float assigned to Uint8ClampedArray rounds/clamps
 ...
 data[j+3]=255;
offCtx.putImageData(image,0,0);
glowCtx.clearRect(0,0,glow.width,glow.height);
glowCtx.drawImage(off,0,0,glow.width,glow.height);
ctx.globalCompositeOperation='source-over'; ctx.globalAlpha=1; ctx.clearRect(...); ctx.drawImage(off,0,0,w,h);
ctx.globalCompositeOperation='screen'; ctx.globalAlpha=.22; ctx.drawImage(glow,0,0,w,h);
ctx.globalAlpha=1;ctx.globalCompositeOperation='source-over';
```
Need `ctx.clearRect` with alpha:false canvas maybe fills black; then draw. Fine. But screen composite of glow (which includes dark background) will brighten whole scene slightly. okay.
- `glowCtx.imageSmoothingEnabled=true`; main ctx smoothing high. Set each configure:
```
ctx.imageSmoothingEnabled=true; ctx.imageSmoothingQuality='high';
glowCtx.imageSmoothingEnabled=true;
```
- Could draw glow first then sharp on top with screen? If draw sharp source-over then glow screen, glow overlay soft. Fine.
- `context.filter` not used.
- Need background arrays:
```
for y,x:
 nx=(x/(W-1)-.5)*2; ny=...
 const d=Math.min(1,nx*nx+ny*ny*.8

);
 bgR=3+4*(1-d); bgG=7+8*(1-d); bgB=15+18*(1-d)
```
This gives center ~7,15,33 and edges 3,7,15. Nice.
- Maybe add subtle checker/grid lines? no.

Need color swatches style inline custom property okay no external. e.g.
`<button type="button" class="swatch active" style="--c:#38d9ff" data-color="#38d9ff" aria-label="Cyan ink"></button>`.
Input value matches.

Need perhaps indicate selected color around panel border? no.

Need use no network requests: no URLs, no fonts external. CSS uses system font. No third-party.

Potential browser tool environment: file:// loading maybe color input works. Canvas and JS okay. Need no module import.

Let's write now.

Need syntax check. Extract script with Python maybe node --check. Also perhaps inspect CSS color-mix support could be harmless. Need run browser.

No python. Use node script to regex.

Now browser reload/inspect initial output and console.

Initial screenshot looks good. But note panel controls wrap Clear to second line; okay though could improve. Initial dye somewhat dim/blurred; visible. Need check motion after load and drag. Use browser motion perhaps captures movement. Need know action parameters maybe no args. Call motion.

Initial motion visible but quite slow and blurred; okay. Dye % increased from 1.1 to 3.9? Hmm metrics from initial reload 1.1%, then motion 3.9% after 2.2s. Dye should decay, not increase. Why? `setScalarEdges(dst)` copies interior to boundary; not enough to increase 4x. Maybe initial `configure(false)` calls `seedInitialScene()` and `project()`, then `render`, `updateReadout`; at that moment dye maybe 1.1% average. Over frames, advection with bilinear interpolation and boundary copy should conserve-ish, but dye can increase due to boundary duplication? Not 4x. Wait metric loops every 4 cells and sum r+g+b / (count*3), so initial around maybe 0.011. After 2s 0.039. This suggests numerical instability / dye amplification. Advection bilinear interpolation should not amplify maxima, but with `setScalarEdges` copying interior, no. Could initial seed get rendered at time zero but fields perhaps not initialized? Let's inspect code: configure(false) calls `allocateFields`, then `seedInitialScene`, sets grid, `render`, `updateReadout`. Initial dye should be some amount. Maybe reload's DOM readout shows "dye 1.1%" before one or more simulation steps? It says motion 0.39, dye1.1. Then motion tool after 2.2s says 3.9%. Could there be a bug in `advect` causing source/dest alias? For dye, `r0.set(r)`, advect(r,r0,u,v,...). Fine. For velocity, `u0.set(u); v0.set(v); advect(u,u0,u0,v0,...); advect(v,v0,u0,v0,...)`. Fine.
But `setScalarEdges(dst)` sets boundary cells; no interior amplification.
Could bilinear interpolation amplify dye sum if velocity field is convergent? Semi-Lagrangian advection with backward sampling is not strictly conservative; it can amplify dye where flow converges, especially if projection incomplete. Pressure with 14 Gauss-Seidel iterations might leave divergence; vorticity confinement and boundaries may cause compression, leading apparent dye increase. Need avoid dye blowup. Dye decay 0.9988 should slowly reduce. If average rises 4x in 2s, something's off. Could be initial seed's dye concentrated at centers and

then after project? No, render from same fields. Perhaps the readout from reload was taken at +1ms before browser loaded fully? It says info ready and grid 160×106, motion 0.39, dye1.1. Then motion at frame1 +0ms maybe after ~? Could be page had run ~? The motion tool might capture 4 screenshots over 2.2s but page loaded earlier. The dye should not quadruple.

Let's inspect visually: initial screenshot first from reload (not attached in context? It says earlier screenshot omitted; maybe first visible is motion 1? Actually motion frames show large smoke plumes quite dim). Initial dye blobs at reload might have been small; over 2 sec they expand hugely due to velocity. Average dye could increase from numerical compression maybe. Need investigate. Could use headless Node to evaluate solver arrays? We can instrument via browser DOM perhaps expose debug functions to compute total dye and divergence, but we can't call unless browser tool supports `type` into some field that can execute? Maybe `browser inspect` might allow JS evaluation through a JS console? Let's see action `inspect` no text arguments. Could modify index.html temporarily to include an auto-test that logs metrics over time to console, then browser reload and inspect console. Console inspect returns all console messages. We can add temporary code that calls `setInterval(() => console.info(...))` and maybe logs total dye / divergence. But final file shouldn't have noisy logs ideally. Could add temporarily, then remove. Or use browser motion and screenshots; clear primarily. Need verify required behavior. But if dye field amplifies, could eventually fill screen and violate clear. Need fix.

Need understand if metric mismatch is due to `setScalarEdges` and pressure / advection. Let's perhaps use a standalone Node simulation with same core class to measure dye mass over frames. But duplicating code is possible by exporting core? Could use jsdom? no DOM. We can extract functions into Node with mocked document/canvas? Hard but feasible with a stub of DOM and requestAnimationFrame. Or write a minimal Node script implementing relevant arrays and functions copied from file via regex? Could load script in a fake DOM environment. Need maybe use `vm` with stub objects. But easier: add a debug expression to `window.fluidApp` and use browser tool maybe `inspect` has no eval. Could perhaps use `browser` action `type` with text into a contenteditable element? no. Could add a `<button id

=debugBtn>` that when clicked logs metrics. Browser tool click can trigger. We can inspect console after click. Or add hidden key handler e.g. pressing "d" logs stats. Then use browser `key` with text "d". This is possible. We can add a diagnostic keyboard shortcut that logs detailed metrics to console (not visible user-facing). Could be kept in final too, harmless. Need use `key` action maybe text "d". Need see syntax. But we can add console logging in `updateReadout` perhaps every second with total dye and mass. Then browser motion/inspect shows console. But final console log spam maybe okay one startup only; temporary remove afterwards.

Let's first check actual `motion` frames after 2 sec: dye did not fill screen much; average 4% perhaps plausible from initial compact dye spreading; but mass should not increase. Tone mapping saturates at high values; total dye could be lower but spread. However readout is average field values, not area. Initial dye maybe 1.1% average; after movement, numerical interpolation can increase mass if divergent flow. Need evaluate.

Potential bug: `setScalarEdges(dst)` after each channel copies interior to boundaries, adding dye to boundaries (N boundary cells ~2%). Not 4x.

Potential bug: pressure projection sign might be wrong! Let's verify carefully. Starting from velocity u, divergence d = (uR-uL+vD-vU)/2. We solve `p = (pL+pR+pU+pD - div)/4`. Rearrange `pL+pR+pU+pD - 4p = div`, i.e. discrete Laplacian p = div. Then subtract gradient p: u_new = u - 0.5(pR-pL). Divergence_new = d - Laplacian p = 0. Correct. So projection works.

But vorticity confinement is applied before projection and can produce compressive forces; projection should remove. 14 Gauss-Seidel iterations not exact, residual divergence remains. Semi-Lagrangian advection can amplify concentrations under converging flow. Still maybe 4x. Need perhaps enforce dye conservation by normalizing total dye after advection to decayed previous total. This is a common trick to prevent numerical gain/loss: compute sum dye before and after, scale dye channels to `before * DYE_DECAY` (or some allowed loss). That would ensure gradual dissipation and avoid blowup. But might reduce visual intensity if advection

diffuses; actually preserving mass keeps bright. Could implement mass conservation with `dyeMassBefore` including interior cells and set scalar edges? Need account boundaries. We can compute sum of r+g+b over all N before copy, then after advection compute sum and scale interior (and edges) by ratio `target/current`, where target=before*DYE_DECAY. But we currently apply decay inside advection. Could remove decay and use global mass scaling. Simpler:
- In `step`, before advect dye compute `massBefore=0; for i 0..N massBefore += r[i]+g[i]+b[i]`.
- after three advect calls with decay=1, compute massAfter; if >1e-6 scale all channels by `scale=(massBefore*DYE_DECAY)/massAfter`, cap scale <= maybe 1.0 to prevent increase; then setScalarEdges each channel. This ensures total mass decays exactly and prevents numerical growth. Need avoid global scaling affecting colors uniformly (fine).
- But boundary copies in advect may add mass; scaling handles.
- Need use loop over all N ; extra 17k*3, small. Could also update dye with local clamp max after scaling maybe not needed.
- Use `const dyeDecay=1` in advect calls; global scale. Or keep decay and target=massBefore*DYE_DECAY; scaling would produce DYE_DECAY² if advect already applies. So set 1.
- Need ensure if user injects dye during step? JS single thread no concurrency.
- Need maybe `massBefore` includes boundaries; after advect with edges. Good.
- Cap scale to `Math.min(1.0, target/current)` because target < before, current maybe small; if current<target, scale>1 would artificially increase. We want no gain; use `Math.min(1, target/current)`. But if bilinear interpolation loses mass (common), current may be lower than target; applying no scale lets it decay naturally, perhaps faster. Fine. This guarantees total dye monotonically non-increasing while running. Great. Need maybe call `setScalarEdges` after scaling? Scaling all N uniformly so boundaries remain copies; no need.
- Could also compute mass per channel? Global sum preserves color ratios mostly; fine.
- Need ensure clear removes all dye; yes.

Potential issue initial readout after reload 1.1% to 3.9% could be because `massBefore` computed after pressure but before dye advect; no

normalization. We'll fix.

Need verify drag injection via browser. First maybe need test after fix. But let's also think about UI width: controls wrap Clear to second line because panel width 382 and color group takes ~? color group: label 20 + input34 + 5 swatches*20+4*6=124 + gaps etc ~200, plus 2 buttons 78+78+gap=165 => 365 + padding? 382-34=348, so wrap. Could widen panel to 420 or reduce swatches/button min widths. Better visually put all controls one row; width maybe 430. At 1200x800, 430px panel okay. Could set width 430px and min. Or reduce `label`字体 etc. Fine. Widen to 430; panel label tag may still fit. Let's calculate: panel inner width 430-34=396. color group: label 19 + gap7 + input34 + gap7 + swatches 5*20+4*6=124 + padding-right9 =200. Pause min78 + gap9 + Clear min78=165, total 365+ maybe gap9 =374 <396. Great. Set width 430. At screenshot currently panel width 382, clear wraps. Need fix. Also swatch active border etc good.

Need maybe add initial scene sharper; upscaling with high smoothing plus glow makes it blurry but fluid sim naturally low-res. Could increase target cells to 22000 (W~180,H~120 at 1200x800 -> 21600) still bounded and work maybe okay. Current 160x106 gives 7.5 px cells, blurred quite a bit. Need visual quality perhaps 180x120 ~6.7 px cells, sharper. TARGET_CELLS=22000, cap W=190,H=130. At 1200x800 W=180,H=120 (21600). Pressure 14*21.6k=302k; still likely fine. Need ensure controls responsive at 1200x800. The addendum says bound simulation resolution/work per frame. 180x120 is modest. Could choose 19000 -> W=168,H=112 (18.8k). Difference minor. Fluid appearance is naturally smooth. Maybe keep 17000 for performance. Need test drag / frame rate. Browser motion shows motion readout decays and frames captured at ~750ms intervals; perhaps frame rate okay. Need perhaps inspect performance with console? Could use requestAnimationFrame

timing metric added to `data-fps`; not currently. Could add. But not essential. Need maybe use browser screenshot after drag to see obvious line.

Let's first apply mass conservation and panel width. Need add `conserveDye()` function or inline in step. Need precise edit.

Add after advect in step:
Before r0.set:
```
    let dyeBefore=0;
    for(let i=0;i<N;i++) dyeBefore += r[i]+g[i]+b[i];
    r0.set...
    advect(..., 1);
...
    let dyeAfter=...
    const target = dyeBefore * DYE_DECAY;
    if (dyeAfter > 1e-6) {
      const factor = Math.min(1, target / dyeAfter);
      if(factor < 0.9999) {
        for(...) { r[i]*=factor;...}
      }
    }
```
Need note `DYE_DECAY=0.9988` per simulation step, at 60fps half-life~9.6s. Good.
Potential issue when adding dye via splat while paused and then later step, massBefore after injection includes it; fine.
Potential issue after clear, dyeBefore=0, target=0, dyeAfter=0; no scale.
Potential issue initial dye mass maybe 0.011*N*3 ~560; after advect could increase to 2000; scale down. Good.
Need maybe scale only interior cells to avoid boundary duplication; all N okay.
Need apply `MAX_DYE` clamp after scaling? factor <=1, so no increase.
Need update metrics perhaps.

Need maybe also velocity mass or energy conservation? Not necessary; velocity decay. Vorticity confinement + projection may amplify but clamp. Good.

Need add stats FPS? Could track steps/time but not required. Perhaps use `document.body.dataset.fps` to verify responsiveness? Could add simple frame counter:
```
let fpsFrames=0,lastFpsTime=0;
...
fpsFrames++;
if(now-lastStats>500){... body.dataset.fps = Math.round(fpsFrames*1000/(now-lastFpsTime)); fpsFrames=0; lastFpsTime=now;}
```
But not needed and extra code. Could be useful to verify performance. Browser inspect DOM text won't show data-* maybe but can maybe `document.body.dataset` not shown. We could add fps readout but UI clutter. Skip.

Need test drag with browser tool. First modify.

Need reload and inspect initial then drag. Also syntax check.

Initial now one row, nice. Dye 0.6%. Need check mass over time after reload via motion/inspect.

Initial scene very dim, too diffuse. Need brighten significantly. Mass conservation fix causes dye value low? Initial screenshot from reload maybe perhaps slightly brighter? Attached motion frames show barely visible. Need improve initial scene and drag visibility. Maybe tone mapping factor 1.55 and dye values low due to global mass correction scaling down drastically. Need perhaps seed more dye and increase render exposure. Also blue/cyan blobs almost invisible due to dark blue background. Need make bright. Need adjust:
- Increase tone mapping coefficient from 1.55 to maybe 4 or 5. For c=0.1, 4*0.1/(1+0.4)=0.286*245=70; visible. For c=1, .8*245=196. Good.
- Increase dye injection amounts: initial center .85 and arms .48; drag amount ~0.14 per splat with overlap ~6 -> ~0.8; should be visible with exposure 4. Current stroke maybe not yet tested. Need initial dye average 0.5% -> 0.005; typical dye in blobs maybe .1; exposure 1.55 gives 33, barely. Exposure 4 gives 70. Good.
- Add colored glow via current glow screen 0.2; fine.
- Could increase seed dye amount by 1.5x and drag amount by 1.3x. Need avoid blowout. Let's make render coefficient 3.8 and initial dye center 1.15, arms .65; drag amount `0.16 + stepLength*0.05`, max .45; pointerdown .9. Initial should be bright. But mass conservation may scale down if advection amplifies; still okay. Dye average maybe 0.8%. Need be visible on load. Requirement small amount, but bright small blobs. Good.
- Could use a sharper color mapping by adding saturation boost: compute `max` and boost channels? E.g. `cr=r*3; ...` enough.
- Need perhaps keep background dark vignette but overlay `box-shadow` darkens edges; center okay.
- Need maybe second pass glow stronger `globalAlpha=.3`.
- Need initial motion more visible. Motion readout ~0.2, velocity slow. Over 2.3 sec, blobs barely move. Need stronger initial vortices / less damping. Drag should be stronger. Initial vortices need visible swirl. Increase vortex speed from 2.35 to 3.3 (max

speed ~2 cells/tick). Background current from .16/.11 to .3/.2. VORTICITY maybe .2. Velocity decay 0.9982 instead of .9972 (half-life 6.4s) and pressure projection should preserve. Need "gradually dissipate" over ~10-20s; fine. Motion metrics will drop from .4 to .2 due to projection. Could use .999 for velocity (half-life 11.5s) but vorticity confinement sustains. Requirement momentum/dye remain visible after release and gradually dissipate. Need ensure not too quickly. Use `VELOCITY_DECAY=0.9985` half-life 7.7s; with pressure losses maybe okay. Dye .9988 half-life 9.6s. Vorticity .18. Need maybe initial motion stronger.

Need test drag first before adjusting? Could drag and see. But initial dim likely drag also dim. Let's perform a drag to see current behavior. Use browser action drag from maybe 300,500 to 900,300 with default cyan. Need avoid panel at top. Use coordinates x=250,y=600 to x=950,y=350. Let's call.

Drag does produce visible cyan plume along path and swirls at endpoint. Great. But it seems initial dye vanished/invisible; drag dominates. Need check after release motion via motion tool. Also need check second drag in another direction. But first maybe brighten initial scene and ensure drag. Current drag start (220,600) line to (980,330) produced a big cloud at right endpoint, so momentum and dye persist. It likely had many pointermove events or one long segment; good. Need see motion after release.

After release, dye cloud barely visible and motion metric drops to .08; visually doesn't move much. Need substantially improve brightness and motion persistence. Need likely initial scene also. Need adjust exposure and dynamics. Why drag cloud dims so much with mass conservation? Dye mass 1.1% average but spread out; exposure 1.55 too low. Need increase exposure to 5-6. Also need maybe use a non-linear gamma that makes low dye concentrations visible: `t = 1 - 1/(1+c*k)` is low for small c; use `t = sqrt(c*k/(1+c*k))` or `t = Math.pow(c*k/(1+c*k),0.65)`. We can use `1 - exp(-c*3)` or rational with square root. Since no exp needed. For c=.02, exposure k=4 -> .08/(1.08)=.074 -> 18; sqrt -> .272 -> 67. For c=.1 -> .286 sqrt=.535 ->131. This makes diffuse dye much more visible but could make whole field glow. We can use `tone(c) = 1 - 1/(1+c*2.5)` perhaps still. Better implement gamma via `Math.sqrt(c*4/(1+c*4))`, which is cheap sqrt x3 per pixel (51k sqrt per frame, okay) and yields bright. Or use `c/(c+0.15)` for c=.02 -> .118 ->30; c=.1 -> .4 ->100. This is easier and has no saturation until high. `t = c*4/(1+c*4)` then `sqrt(t)` gives c=.02 t=.074 sqrt=.27; c=.1 t=.286 sqrt=.535; c=.5 t=.667 sqrt=.816; c=1 t=.8 sqrt=.894. Nice. Need avoid background glow from tiny dye everywhere; can add threshold `c = Math.max(0, c - .002)` to suppress. But low dye everywhere from interpolation might create blue haze; could be fine, fluid smoke. Use `Math.sqrt(c/(c+0.12))` maybe. For c=.02 -> .378 ->92; c=.1 -> .675 ->165; c=.5 -> .898 ->220. That's very bright. Need calibrate. Could use `t = c*3/(1+c*3); t = sqrt(t)` perhaps c=.02 -> .238 ->58; c

=.1 -> .48 ->118; c=.5 -> .775 ->190; c=1 -> .866 ->212. Good. soft glow. Use `const EXPOSURE = 3.0`. Then call `Math.sqrt(t)`. Need maybe saturate color more: subtract a fraction of min channel? not necessary.
- This will make initial blobs bright and drag plume bright.
- Add `globalAlpha=0.28` glow and maybe draw glow via CSS `filter: blur(6px)`? The low-res glow already.

Motion persistence: Need increase velocity decay and vorticity confinement. Motion metric after drag from .22 to .08 in 2s; likely pressure and decay. Need keep flow swirling after release. Could adjust:
  VELOCITY_DECAY from .9972 to .9990 (half-life ~11.5s).
  VORTICITY from .15 to .28 (more sustained eddies).
  pressure iterations maybe 18? More incompressibility actually may remove energy from divergent injection but preserve rotational. 14 fine.
  initial vortex speed 3.2.
  background current .24/.16.
  drag push maybe increase from .9*stepLength (max2.4) to 1.1*stepLength (max3.0); MAX_SPEED=7.0. Need ensure second drag can alter flow; strong enough.
Potential risk vorticity confinement with .28 + decay .999 causes instability / energy growth and velocity saturating everywhere. Need clamp and pressure. Could test. Need maybe use .22. Let's reason: vorticity confinement force per cell = eps*omega ~.2*curl. For shear velocities ~1, curl ~.2, force ~.04/tick, sustained; moderate. With decay loss ~.001*velocity=.001, confinement dominates and could amplify. But projection removes some. It may keep flow at moderate .5. Could lead to noisy speckles. Use .18. Need perhaps use decay .9988 (half-life 9.6s), confinement .22. That should persist.

Need understand metric is average speed over whole grid. After drag, flow concentrated; metric .08 could still mean local speed ~1.0 in 8% of grid. Visual barely moving in motion frames (cloud shape almost unchanged). Perhaps pressure projection + low velocities actually cause slow movement. Need strong drag velocities. Increase push. The drag stroke from x=220 to 980 across

760px and y -270: grid length ~107 cells; steps≈60, stepLength≈1.8, push=1.62. Overlap radius 6 => local velocity ~6 (clamped). So initial after drag should be fast, but after 2.2 sec metric .08; maybe pressure projection + advection damp heavily. Why? Maybe `project` is over-damping because we call it twice each step and pressure solve not reset? pressure.fill(0) yes. Maybe pressure projection sign correct but boundary conditions weird. Let's test with a uniform horizontal band: divergence zero; pressure should be zero; velocity self-advection should preserve (except boundaries). So drag line should produce moving dye. But if pressure solve uses boundary conditions with `setScalarEdges` that duplicate p and in-place Gauss-Seidel, may produce nonzero p even for divergence-free field due to boundary artifacts? At boundaries, divergence of uniform horizontal flow with no-slip wall is nonzero (u at left boundary set -u interior), so pressure acts to enforce no-penetration, creating vortex pair at ends. But interior uniform flow remains. Dye along line should advect right/up. Motion frames show cloud at right endpoint; maybe it did drift but screenshot only subtle. Need perhaps increase brightness so movement visible. Could also add velocity visualization via trails? no.

Need perhaps use browser motion with drag sequence after brightening. Need check clear and second drag. Need maybe adjust mass correction to preserve more local concentration. Semi-Lagrangian advection with global mass correction spreads dye; that's physically diffusive due to bilinear interpolation. Fine.

Need maybe use MacCormack/BFECC advection to reduce numerical diffusion, but complexity not necessary. Could increase sim resolution to 20000; mild.

Need maybe min dye threshold in render to preserve contrast. If we use sqrt, diffuse haze visible. Could use a combination:
```
function map(c) {
 const x=c*4;
 return Math.sqrt(x/(1+x));
}
```
If c very small .001 -> sqrt(.004)=.063 -> 15 extra; across background gives slight glow. okay.

Need maybe implement color saturation:
`const lum = 0.18*cr+0.72*cg+0.1*cb; cr = Math.max(0, cr - lum*0.2)` etc. Not necessary.

Need perhaps dynamic amplification based on max dye? Could use `EXPOSURE=3.2`.

Let's modify constants and render. Also

maybe initial seed color amounts. Need be careful still "small amount" not full screen; brightness okay. Let's edit multiple entries in one call:
- VELOCITY_DECAY 0.9988
- DYE_DECAY maybe 0.9991 (half-life 12.8s) because mass correction ensures fade. Requirement gradually dissipate; 0.9988 already. Keep.
- VORTICITY 0.22
- MAX_SPEED 7.0
- add render EXPOSURE constant maybe `const RENDER_EXPOSURE = 3.4;`
- vortex multiplier 2.35 -> 3.1
- background current .16/.11 -> .24/.16
- seed center .85->1.05, arms .48->.62
- drag push max 2.4->2.8 and factor .9->1.05; amount .10+ .04*step -> .14+.05*step, max .4; pointerdown .7->.9
- glow alpha .20->.26
- render mapping with sqrt.

Need also maybe increase initial scene to visible on load; perhaps 3 seed vortices with 4 splats; okay. Need maybe set color from hex; bright.

Let's apply.

Need reload and inspect initial.

Initial scene now very visible, perhaps too much dye? It's three blobs ~1/3 screen, still "small amount" arguably. Could be acceptable. Need verify motion initial perhaps swirls. Use motion tool.

Initial motion frames show slow swirling and dye spreading too much across screen (very large plumes). Perhaps because render sqrt amplifies tiny diffuse dye; okay visually but could be too hazy. Need maintain persistent swirling flow; frames show subtle changes. Need perhaps reduce overall spread with less aggressive exposure or use unsharp contrast. Maybe not critical. Need check drag after release and second drag, Clear. Need perhaps use a different color swatch to verify selector too. Need maybe test Pause/Resume. We have limited time but plenty. Need ensure no instability.

Need perhaps inspect more carefully motion after release with new settings. Reload to clean state. Then clear first? To isolate drag behavior, test Clear then drag. Requirement says Clear then drag fresh flow. We can do sequence: click Clear to blank; click a color swatch (rose) maybe; drag from (250,600) to (950,350); screenshot immediately; motion after release; second drag in another direction (e.g. from 900,650 to 300,250 using lime); screenshot/motion; Clear and drag again maybe. Need use browser tool sequence. Need understand clicking coordinates from 1200x800. Panel swatches at x≈70 cyan, 111 rose, 151 violet, 191 lime, 231 amber, y=89. Pause at x=282,y=89; Clear x=368,y=89. Need use click. Could also use keyboard 'c' for clear. But need verify Clear button specifically, so click. Need ensure click tool uses x,y. Let's reload first to reset initial scene, then click Clear. We'll need maybe wait after clear? Click returns screenshot maybe immediate. Then drag. Need maybe use `motion` after release to sample. Let's do.

First reload then click Clear.

Initial scene looks good now. Need test clear.

Clear works. Need select a color maybe click rose swatch at x=131? From screenshot swatches: cyan center x~111, rose x~131? Actually panel starts x=18, padding 17 => content x=35. label "Ink" x35-53, color input x62-96 (34); swatches group x103 onwards: first center~111, gap6 => second center~137? Let's zoom mentally from screenshot: cyan circular at 111, rose at 131? Actually width 20 and gap6 => centers 111,137,163,189,215. In earlier screenshot panel: input square from 62 to96; first swatch center 111; second 131? Could be gap? CSS `.swatches {gap:6}` and button width20, so second center=111+26=137. Yes. Pause button starts x245 (screenshot ~245?), clear x330. We clicked x368 Clear successfully. Good. Need click rose x137,y89 or lime x189,y89. Let's click lime perhaps x189. Need verify color selector active via DOM maybe class not visible; screenshot will show outline. We can use click and inspect. Let's select rose maybe x137. Then drag from lower-left to upper-right; should see rose. Need ensure click on swatch doesn't start stroke on canvas (it's panel). Let's do.

Color selector works (rose active and input). Need drag fresh flow. Use from (250,600) to (900,300) maybe. Then screenshot.

Drag clearly follows path and forms big vortex at endpoint. Good. Need after release continues swirling and gradually dissipates. Use motion tool; if frames show shape moving/deforming, good.

Motion frames show huge diffuse pink clouds filling canvas, not clearly swirling. The pressure projection + vorticity confinement seems to create large-scale rollup, but dye spread too much from a single drag. Need maybe more localized fluid-like flow. Also motion metric remains .14, so velocity persists. Need visual shape changes subtle but present, top cloud grows/shifts. Could be acceptable but want better swirling. Need perhaps reduce initial drag dye amount and exposure gamma to keep stroke narrow and swirls crisp. Current glow/exposure makes diffuse dye huge. The initial drag screenshot before mass conservation showed a narrow cyan trail; now with sqrt exposure, it's broad. Need perhaps use less aggressive low-end mapping: use exponent 0.75 rather than 0.5, or exposure 2.2. Need brightness enough for initial scene. Could increase dye concentration while using less low-end amplification. E.g. mapping `t = (cr/(1+cr))^0.72` with exposure 3.4. For c=.01, cr=.034, t=.033, ^.72=.084 ->21 (vs sqrt=.18->44). For c=.1, cr=.34,t=.254,^.72=.373->91 (vs sqrt=.504->123). For c=.5,t=.63,^.72=.72->176. This reduces haze. Could use `Math.pow(t,0.72)` — pow is more expensive than sqrt but 51k per frame okay. Could use `t * (1.4 - 0.4*t)` as cheap gamma-ish: for t=.033 ->.045; too low. `Math.sqrt(t)*Math.sqrt(Math.sqrt(t))` = t^0.75, requiring 2 sqrt per channel. Could do `const s=Math.sqrt(t); const tr=s*Math.sqrt(s)` = t^.75. That's 2 sqrt per channel. 17k*3*2=102k sqrt/frame; okay. Or use `Math.pow(t,0.72)`. Simpler. Need optimize perhaps no issue.

Another approach use a threshold to eliminate low-end dye:
```
let cr=Math.max(0,r[i]-0.004)*4.0; 
t=cr/(1+cr); gamma sqrt
```
This suppresses diffuse haze but still bright concentrated dye. With mass conservation, concentrations in clouds maybe .01-.05 (because average 1.3

% across scene; peak maybe .3). Subtracting .004 shifts faint edges dark. Could add threshold .006. Need maybe initial blobs stay. This may produce crisp swirls. Let's estimate from visual: clouds are bright ~100/255, mapping sqrt with exposure3.4 => t=.16 => cr=.19 => c=.056. So values ~.05. Threshold .004 negligible. Faint haze maybe c=.002 gives t=.0068 sqrt=.082 ->20; could threshold .002. Need perhaps use gamma 0.75 instead of sqrt to reduce haze.

Need more obvious swirling flow. Could reduce mass diffusion by using higher grid resolution and perhaps BFECC advection. But requirement approximate fluid; visual can be diffuse. The drag creates large vortex ring rolling, which is fluid-like. Motion frames show it slowly rotating; okay. Need maybe second drag in another direction clearly changes flow. We'll test.

Need perhaps check Pause/Resume and Clear after drag. Need maintain output.

Concern: Clear auto resumes, so if user had paused then Clear resumes; is that a problem? likely fine.

Concern: Color selector input native color with value changes; no external. fine.

Concern: Pause/Resume button text and behavior. Need verify. Use click Pause then motion maybe no changes; click Resume then motion. We can do in sequence. But don't overdo time. Need test second drag and clear. Let's first second drag in another direction with lime color. Need select lime swatch x189,y89. Then drag from e.g. (900,650) to (300,250) (up-left) crossing existing pink flow. Need inspect screenshot and maybe motion. Do that.

Interesting by time click swatch, pink dye has spread into large dark/pink bands; motion .04, dye .7. Need second drag. Use from (900,650) to (300,250) with lime. Ensure panel at top-left doesn't intercept end at 300,250? panel ends y~142, so fine.

Second drag produces a bright lime diagonal plume from bottom-right to upper-left. It responded strongly and changed flow. Pink residual dark. Good. But lime color appears pale/yellow-white because color [0.61,1,0.41] with sqrt mapping -> all channels high; saturation washed out. Could improve color rendering saturation by boosting channel differences: e.g. compute luminance and apply saturation multiplier:
```
const lum=0.2126*tr+0.7152*tg+0.0722*tb;
tr = clamp(lum + (tr-lum)*1.35)
...
```
This keeps colors vivid. For lime, tr~.8, tg~.9,tb~.7; lum~.85, saturation 1.4 -> .78,.92,.64, still pale. Need more aggressive 2.0 -> .75,.95,.55. But initial cyan already good. Could use dye color values with lower minor channels: preset lime #9cff68 (0.61,1,.41) naturally; sqrt compresses differences. A saturation boost helps. Need maybe apply to raw dye channels before tone mapping:
```
const mean=(cr+cg+cb)/3; cr=max(0,mean+(cr-mean)*1.35) ...
```
Then tone map. Could make colors vivid. Not required; color selector works. But visual quality nice.

More important: after second drag, need check continues swirling and responds to second drag. It does. Need check Clear then drag fresh flow; earlier we did clear then first drag, yes. Need perhaps after second drag clear again then drag to ensure fresh flow. Also need check Pause/Resume. Need perhaps test that clear resets velocity to zero and fresh drag can start a new flow. We saw clear readout 0/0 then drag. Good. Could also test pause/resume behavior via click and screenshots. Need maybe inspect that Pause actually stops evolution. Use click at x283,y89 (Pause). Then screenshot/motion; button should say Resume and state Paused. Then click Resume and motion. Let's do. Need note after second drag currently running; click Pause.

Pause works text/state. Need confirm no evolution while paused via motion; motion tool frames should be identical.

Pause frames identical. Good. However visual after second drag and some time is mostly green haze filling whole screen, dark navy cracks. That's not ideal: dye appears to fill screen rather than persistent swirling flow. Mass conservation plus sqrt exposure makes low dye visible everywhere; perhaps we need reduce low-end response to make concentrated flow distinct against dark background. Need improve. Requirement says small amount of colored dye initially, drag injects dye, momentum and dye remain visible and gradually dissipate. It doesn't say background must be dark, but fluid should be visible. The green haze is dye spread by flow; okay but less attractive. Need maybe adjust render mapping to a higher gamma (e.g. t^0.75) and use saturation. Could also reduce glow pass from 0.26 to 0.18 because glow overlay with screen causes haze. Need see current paused screenshot: green background everywhere likely due to sqrt mapping of tiny dye and glow. Need reduce low-end. Let's implement color mapping with optional gamma .75 and saturation boost. Maybe use `t = c/(1+c)` then `pow(t,0.75)` plus exposure maybe 5? Need calibrate.

Let's derive raw dye concentration from paused screenshot: green haze brightness ~80-100 over background 15. With sqrt mapping, to get 90/255 => tr≈.35 => t=.1225 => cr=t/(1-t)=.14 => c=cr/3.4=.041. So even low haze has c~.04. That's not tiny; mass is 1.6% average, so c~.04 in green channels is plausible. With gamma .75 and exposure 3.4: t=.14/(1.14)=.123; t^.75=.208 => 50 brightness. Still visible but darker. For concentrated c=.3: cr=1.02,t=.505,^.75=.598=>145; with sqrt would be .71=>175. Need maybe increase exposure to 5: c=.04 -> cr=.2,t=.167,^.75=.26=>64; c=.3 -> cr=1.5,t=.6,^.75=.682=>167. Good. So use `RENDER_EXPOSURE=5` and gamma .75. Initial blobs with c~1: cr=5,t=.833^.75=.867=>212, bright. Good. Faint c=.002: cr=.01,t=.0099,^.75=.031=>8. dark. This reduces broad haze. Great

. Need implement gamma .75 without `Math.pow` maybe use `Math.sqrt(Math.sqrt(t*t*t))`? `t^0.75 = sqrt(t*sqrt(t))`? Let x=sqrt(t); t^.75 = sqrt(t)*sqrt(sqrt(t))? Actually t^.75 = t^.5 * t^.25 = sqrt(t)*sqrt(sqrt(t)). Need two sqrt. For each channel:
```
const sr=Math.sqrt(cr/(1+cr));
const tr=sr*Math.sqrt(sr); // sr=t^.5; sqrt(sr)=t^.25; product=t^.75
```
Yes. Two sqrt per channel. Fine.
Saturation boost on tone-mapped values:
```
const lum=.2126*tr+.7152*tg+.0722*tb;
const sat=1.35;
const outR=clamp(lum+(tr-lum)*sat,0,1)
...
```
Need clamp function available. For lime, tr~.55,tg~.68,tb~.48, lum~.63; sat1.45 -> .51,.70,.41, more vivid. For cyan, tr~.3,tg~.8,tb~.9, lum~.69; boost -> .12,.85,.99. Nice. For amber, etc. Need maybe black background unaffected: tr=tg=tb=0 -> lum=0, outputs 0. Good. For white dye, all equal -> unchanged. Great. Need this. Also reduce glow alpha to .2 maybe. The glow pass adds broad haze; use .18. Could maybe use glow only after saturation? Glow currently uses same tonemapped color, so screen overlay adds. Fine.
- Need perhaps add a small threshold to color raw c: `Math.max(0, r[i]-0.001)*EXPOSURE`. Might suppress extremely low values. Could use `Math.max(0, ... - .0015)`. With c=.002 => .0005*5=.0025 t=.0025 ^.75=.011=>3. fine. no need.

Need also perhaps increase pressure iterations to 18 to reduce residual divergence and dye compression/spreading. But mass conservation handles. More iterations may improve swirling, but work ~+68k operations, still okay. Could set 16. Need perhaps better incompressibility. Yes set 16. At 160x106 ~272k loops. Fine. Need maybe

velocity self-advection more stable.

Need maybe reduce vorticity confinement from .22 to .18 if flow fills screen too aggressively? The large haze from dye spread comes from high velocities + numerical diffusion. Lower vorticity might reduce chaotic mixing; but requirement wants swirls. Could keep .20. Need perhaps use a higher-resolution grid to reduce numerical diffusion and keep dye trails crisp. Set TARGET_CELLS=21000, max W=190,H=130 -> at 1200x800 W=180,H=120=21600. 27% more cells/work; still likely responsive. Need check FPS perhaps browser motion frame timing not enough. Could use dynamic step cap. At 1200x800, JS ~ maybe 10ms/step; two steps max ~20ms; still ~60fps maybe. Need maybe not risk. Current 160x106 is fine. Numerical diffusion due to semi-Lagrangian is inherent; higher grid helps. Could set 19000 -> W=169,H=113=19.1k, modest. Let's use TARGET_CELLS=19000, caps 190x130. At 1200x800 W=169,H=112? compute cell=sqrt(960k/19000)=7.11; 1200/7.11=169, 800/7.11=112.5=>113. grid 19097. About 12.5% more. Nice. But browser inspect will show 169×113; need no issue. Work per frame ~>20% maybe. Controls still responsive. Could keep current to avoid risk. Need perhaps test performance with current; browser motion captures ~700ms intervals but no FPS. Could add an FPS readout temporarily? Not needed.

Need fix visual color mapping. Let's edit. Also perhaps add `const SATURATION=1.35` constant. Need ensure clamp function accepts 0,1 and works. Good.

Edit relevant block and constants.

Need perhaps test performance after pressure iterations 16. Could browser reload and inspect initial. Need maybe check no console errors.

Initial scene now much better: distinct vivid swirling blobs on dark background. Great. Need check motion after load maybe swirling visible. Use motion.

Motion frames show fluid-like slow plumes, dye moves and dissipates. Good. Need perhaps screenshot after reload showed initial vivid blobs, then after 2.3 sec they spread into giant plumes. It's okay. Need maybe improve initial seed to avoid full-screen spread quickly; perhaps reduce vortex speed or decrease gamma? But requirement persistent swirling, so motion across screen is good. Need focus on required checks. We need re-run representative checks after final modifications: Clear, drag, release motion, second drag, Clear + fresh drag, Pause/Resume maybe. We already tested earlier version; after final modifications only render and pressure iterations changed, behavior should still work. Need recheck affected behavior with final version. Need perhaps use browser tool to sequence quickly. We have ~? 15 minutes, likely enough. Need maybe add a performance check to ensure 1200x800 controls responsive. Browser tool is at 1200x800; we can click and drag quickly. Need perhaps monitor FPS via console not necessary.

Need maybe check that pressure iterations 16 didn't cause significant lag. Browser motion tool frame intervals ~800ms, likely tool capture interval not render. Could inspect console no errors. Need maybe add `data-fps` to body and DOM? Could use browser `inspect` maybe returns body dataset? It returned only text. We could add an FPS readout to UI maybe `motion 0.25 · dye 0.6%` no FPS. To verify performance, could add `document.body.dataset.fps` and perhaps browser inspect doesn't show attributes. Could set hidden element's text and inspect DOM output includes hidden text? Probably. But maybe not needed; we could add a debug keyboard shortcut that logs fps. Could use `key` to trigger. Or just use browser motion responsiveness; clicks worked.

Need perhaps test final clear + drag. Let's do sequence:
1. Click Clear (should resume and zero). Need note current running state is true; clear works.
2. Click maybe violet swatch to verify color selector after final changes.
3. Drag from (250,600) to (900,300) — check screenshot.
4. Motion after release.
5. Second drag from (900,650) to (300,260) maybe with amber swatch — check response.
6. Clear then drag again maybe simple short drag to show fresh flow.
7. Pause/Resume maybe click and motion perhaps we already did; after final changes need maybe check button text. Could do quick click Pause -> inspect DOM -> click Resume -> inspect DO

M. No need motion again.
Need perhaps avoid too many tool calls? okay.

Let's first click Clear.

Clear works. Need select violet x163 maybe; then drag.

Color selector works. Drag.

This is excellent: drag trail with a clear vortex roll at endpoint. Need after release motion. Use motion.

Hmm motion frames here are already huge diffuse purple clouds, not the trail/vortex from drag screenshot. Why did drag screenshot show concentrated plume but motion frames ~2.5s later show huge clouds? Wait perhaps `motion` tool starts after some delay from drag; frame1 at +0ms but screenshot first could be much later than drag screenshot (browser tool latency maybe many seconds between calls). It shows dye already spread across screen. It does move slowly but not obviously swirling; motion readout .17 -> .14. Need maybe ensure persistent swirling flow more localized and visible. Maybe the issue is simulation is running at many steps between tool calls (seconds), and dye spreads quickly due to high velocity. Requirement says momentum/dye remain visible after pointer released and gradually dissipate; they do remain visible. Need "dye follows drag, continues swirling, and responds to second drag in another direction." The frames show cloud deformation, maybe slow swirling. Need perhaps make swirling more obvious by adding more vorticity and less dissipative advection. Need maybe use higher resolution / BFECC to preserve fine structure. Let's think.

Maybe browser `motion` tool captures screenshots at ~800ms intervals, but between drag action and motion call there might be a few seconds (model processing time), so dye has already spread. That's okay. Need sample flow after release at shorter intervals. We can call `motion` immediately after a drag with no delay, but tool call latency still maybe ~? We can perhaps use `browser` action `motion` with one combined sequence? No tool chaining maybe can call multiple actions in parallel? The tool wrapper allows multiple independent calls in same block, but would run concurrently; not good. Could perhaps use `drag` then `screenshot` quickly. Already screenshot from drag shows concentrated trail. Need perhaps call `motion` directly after a fresh clear and drag with minimal reasoning; we can do with no user-facing text between calls. That may capture earlier. But current motion frames show large clouds likely due to 2.5 sec only; the previous drag screenshot itself was at +0ms after drag but maybe during drag, and browser drag tool itself may take ~few hundred ms. Need maybe reduce velocity to prevent dye spreading so fast. Drag push ~1.9 per splat, overlapping to max 7 cells/tick. At 60fps, 7 cells/tick * 7.5px =52px/frame =3150px/sec, so dye crosses screen in 0.4

sec. That's too fast! It's why clouds fill screen quickly. Need lower max speed or drag force. Use MAX_SPEED=3.5 or 4 cells/tick (~30px/frame=1800px/s), still fast but less. Could use fixed dt less than 1 (e.g. 0.55) in advection/projection? The entire solver assumes dt=1; we can scale velocity storage to lower values and injection forces lower. Need make flow slower and swirls more visible over time. Current velocities from drag saturate at 7; after 2.5sec they decay to average .14, but local velocities maybe 1-2. Need reduce injection push:
- push factor from 1.05 to 0.55, max1.5.
- MAX_SPEED=4.0.
- initial vortex multiplier from3.1 to2.4 (speed ~1.45).
- background current .24/.16 maybe .18/.12.
- VORTICITY .22 might sustain swirls.
- VELOCITY_DECAY .9988.
This would keep dye trail more localized and swirling visible. Need sensitivity to second drag still okay. Need perhaps pressure projection creates vortex roll at endpoint; with lower speed still. Need perhaps dot swirls. Let's calibrate: drag stepLength ~1.8, push=0.55*1.8=.99, overlapping ~6 ->6, clamp4. So local velocity 4 cells/tick (~30px/frame), still crosses 1200px in 0.67s. Could use push factor .35 -> .63*6=3.8 clamp3.5; ~26px/frame, 0.77s. Fine. Need maybe use dt scaling in advection instead of lowering injection: store velocities in cells/tick but use `advectionDt=0.5` when backtracing, while vorticity/projection still use full. But projection divergence-free property with scaled advection still okay; velocity itself decays. Could use `ADVECTION_DT=0.6` parameter to advect. For velocity self-advection, use px=x - velU[i]*0.6; dye likewise. This effectively slows movement without altering force scale. Pressure projection still based on full velocity; divergence-free remains. Need maybe semi-Lagrangian stability. Could add `const FLOW_SPEED=0.55` and multiply u/v in advect backtrace. That would reduce spread by

~45%, while keeping velocity metric and pressure dynamics. But drag injection still saturates; okay. Need perhaps initial scene motion slower but visible over 2s. Could use 0.65. Need perhaps not confuse physical units.

Alternatively fixed simulation step dt=0.6 globally including pressure? Pressure projection is independent of dt; velocity force injection per event and decay per step need scaling. Advection scaling enough.

Need perhaps not over-tune; requirement says swirling flow, not necessarily localized. But visual frames of huge purple clouds with dark holes look like smoke, still fluid. Need perhaps add more crisp swirl trails by reducing numerical diffusion. BFECC advection could help, but more complexity/time. Let's assess from screenshot: after drag, purple trail with bright curl at endpoint. After ~2.5s, two huge clouds and a dark central band. This is actually fluid-like vortex roll; maybe swirling flow visible. Need perhaps sample at 0.8s intervals: motion frames show upper cloud shape gradually shifting left, lower cloud shape shifting down; slow swirling. Fine.

Need perhaps better verify second drag in another direction with final version. Let's do select amber or lime, drag downward/upward crossing current flow; screenshot should show new bright trail and deformation. Need maybe use color amber x215,y89. Then drag from (900,220) to (350,650) (down-left) or from (300,650) to (900,250). Use a different direction than first (first up-right, second down-left maybe opposite). Need check response. Let's do quickly.

We have <5 min. Need finalize quickly. Need perhaps second drag check can be brief then clear + fresh drag + pause/resume perhaps. Need ensure final file present. We can skip extensive tuning. Current file already saved. Need maybe one essential issue: motion after release indicates dye persists but maybe too diffuse. Still meets requirements. Need check second drag and clear/resume soon. Need maybe use one or two calls. Also need perhaps check Pause/Resume after final version. We have already tested before rendering changes; button logic unchanged. Could still quickly click Pause/Resume. Need prioritize final report. Let's do second drag with amber (x900,y650 to x300,y250 maybe direction up-left; first up-right; different). Then clear + drag again. Could combine? browser actions separate. Need perhaps use `multi_tool_use.parallel` not appropriate for dependent sequence. Use sequential calls quickly.

Second drag: from (900,650) to (300,240). Need note existing purple flow has faded. Screenshot should show amber trail.

Second drag clearly responds with amber flow in opposite direction and fine eddies. Great. Need clear then fresh drag. We can maybe click Clear then drag in one tool call? No, need two calls. Time ~4 min. Do click Clear, then drag short. Also perhaps pause/resume quick click after. Need maybe final syntax check and file size. Let's do clear.

Clear blank. Need fresh drag quick. Use maybe cyan selector default? currently amber active; no need. Drag from 400,500 to 800,500 horizontal to show fresh flow.

Fresh flow works. Need perhaps pause/resume final check quickly. Click Pause then Resume maybe two calls. Need perhaps no need, but requirement controls. We tested earlier version. Could do one click Pause and inspect DOM, then Resume. Time maybe 3 min. Let's do both quickly perhaps one tool call each. Need maybe use `key` space for pause/resume? click is better. Let's do Pause click then Resume click (no screenshot reasoning).

Pause works. Resume click.

Need finalize. Need maybe run final `ls -l` and syntax check, perhaps check file exists. Already. Need maybe maybe remove debug console.info? It's fine. Need perhaps mention unverified: long-term dissipation, precise FPS on other viewport sizes, touch input, custom native color dialog. Need report checked behaviors. Need perhaps ensure `index.html` saved; yes. Could maybe make one final check `node --check` and `ls`. Do quick.

Need final response concise, mention what actually checked and behaviors remain unverified. Need mention implementation: stable fluids with velocity/dye advection, pressure projection, vorticity confinement, bounded 160x106 grid at 1200x800, initial seeded vortices, controls. Need say browser checks:
- initial scene visibly colored with motion frames showing swirling
- clear resets motion/dye 0.00/0.0%, title running; fresh drag starts flow
- drag from lower-left to upper-right produced dye trail and endpoint vortex; after release motion frames showed plume continued moving/deforming and readout retained nonzero motion/dye
- second drag opposite direction with amber changed flow and created new trail
- Pause/Resume toggles state, frozen frames while paused; color swatches changed selected ink
- console had only startup info, no errors
- unverified: long-term complete fade, touch/pen, very small/large viewports/resize, exact sustained FPS (though controls responded), native OS color dialog. Need maybe not overstate "frozen frames while paused" we did earlier version; after final rendering changes only rendering, not logic; we verified Paused state but not motion frames after final changes. Earlier pre-final we did motion frames identical. Could say "Pause/Resume state toggling checked; frozen-frame behavior was checked before the final rendering tweak" maybe too detailed. User asked briefly report what actually checked and which remain unverified. Need be honest. We can say "Pause/Resume toggled and paused-frame stability was observed in an earlier pass (same control logic)." Fine. Need mention no network. Could mention file path clearly.

Need ensure not too verbose. Let's craft final with 2 short sections.