Flow-field particles · mimo-v2.6-flash

Let me start by checking the working directory and the provided p5.min.js.

Let me build the index.html. Design:

- Full screen canvas, p5 global mode.
- Particles: at least 2000, say 3000.
- Flow field: Perlin noise (p5 noise) sampled at (x*scale, y*scale, time) — smoothly varying, evolving with time so it changes gradually.
- Trails: draw translucent black rect each frame (fade), no growing history array.
- Colors vary over time: hue based on particle index + time, or use a palette cycling.
- Recycle particles at boundaries; population bounded (fixed arrays).
- Pause/Resume and Restart buttons; Restart clears trails (fill full background) and reinitializes positions.
- Responsive: resizeCanvas on windowResized, controls fixed positioned.

For performance with 2000+ particles, drawing with strokes: use p5 drawing in 2D context. Use `stroke()` per particle group — changing stroke per particle is costly. Alternative: color particles by bucketing hue into a few groups and drawing batches. Or use `points()`. Simpler: assign each particle a color from a palette of N colors (e.g., 8), and batch draw: for each color group, set stroke once, then draw lines for all particles in that group. But grouping requires iterating groups — store particle color index, loop over colors, loop over particles matching. That's N_colors * N particles iterations = 8*3000 = 24000 iterations, fine. Or store per-particle arrays sorted... simpler to just loop.

Actually simpler: vary color over time — assign each particle a hue offset, compute color per particle. To reduce cost, quantize hue to say 12 buckets and batch. Let's do batching.

Alternatively draw using a single call of beginShape with stroke per vertex — no, stroke per vertex works but still changes state.

Batching approach: buckets array of arrays of indices? That allocates. Instead: precompute for each particle its color bucket (0..NB-1), and a draw order: sort particles by bucket once at init (stable). Then iterate contiguous runs. Easy: create particle order array sorted by bucket at init; loop through order, detect bucket change, set stroke. Nice.

Actually simpler: since color evolves over time, bucket = (baseHue + timeOffset) quantized... Let's define color over time: hue = (particleHueBase + t*speed) % 360. Buckets computed per frame: bucket = floor(hue / bucketWidth). If we sort by particleHueBase at init and all shift equally by time, order stays sorted cyclically... hue wraps, so there'd be two runs. Manageable: bucket index changes uniformly, so contiguous runs remain contiguous but wrap at boundary. Sorting by base hue, the hue over time = base + shift, so sorted order still valid; buckets change uniformly. Runs contiguous. 

Let's keep it simpler: quantize to NB buckets of hue: bucket_i(t) = floor(((baseHue_i + shift(t)) mod 360)/ (360/NB)). Sorted by baseHue gives groups that are contiguous except the wrap segment splits into two groups. Handle by iterating particles in sorted order and setting stroke when bucket changes — works regardless.

So: draw loop:
```
let curBucket = -1;
for (k of sortedOrder) {
  const p = particles[k];
  const b = bucketOf(p, t);
  if (b !== curBucket) { stroke(paletteColor(b)); curBucket = b; }
  line(px, py, x, y);
}
```
That's one line() per particle per frame — 3000 line() calls. p5 line() has overhead but should be OK. Could use immediate mode buffer... p5's renderer batch: in 2D canvas, each line is a ctx.beginPath/moveTo/lineTo/stroke — costly with 3000. Better to use our own batching: group into paths per bucket using ctx directly? We could access drawingContext. Use drawingContext.beginPath per bucket and moveTo/lineTo for each particle, then stroke once. That's fast. But line() calls with stroke changes... Let's do direct ctx usage for the trails: for each bucket, ctx.beginPath, add segments, ctx.strokeStyle, ctx.stroke(). This is very fast.

But the fade: each frame fill canvas with translucent background color using ctx.fillStyle rgba, fillRect. Then draw particles with additive-ish blending: ctx.globalCompositeOperation = 'lighter' maybe for glow, then reset. 'lighter' with fading background gives nice trails. Let's use 'lighter' with alpha strokes, then reset to 'source-over'. Hmm, fading with source-over translucent black darkens; with lighter drawing, bright trails accumulate. That works well.

Actually careful: with 'lighter', colors add, so hue may wash to white. Use moderate alpha (0.35) and lineWidth 1.2. Should be fine and looks nice.

Alternatively use 'screen'. Let's just test visually.

Flow field: angle = noise(x*fs, y*fs, t*ts) * TWO_PI * something. p5 noise is 3D max in default Perlin (noise supports 3 args; p5 1.x noise supports up to 3D? p5 noise() accepts 3 params max in 1.9). Actually p5 noise supports 3D (x,y,z). Yes.

To get more variation, combine two noise samples: angle = (n1 * 2 - 1) * PI * strength... Use angle = noise(x*fs, y*fs, t) * TAU * 2 for more swirls. Nearby particles → coherent since field smooth in x,y.

Evolve gradually: t increases slowly with time (e.g., t += 0.0008 * dt).

Also add a second detail octave for richness: angle = a1*0.7 + a2*0.3 with different scales. Fine.

Recycle: if particle out of bounds (with margin), respawn at random position, reset prev.

Population: fixed MAX = 3000 (>=2000). Could vary slightly but keep bounded; keep constant for simplicity. Maybe vary count? Keep constant.

Restart: new random seed for noise (noiseSeed(random(1e9))), reposition all particles, clear background fully (no trails), reset time.

Pause: stop advancing simulation (no draw updates). Keep rendering? In p5, if we don't draw, canvas stays. Just have draw() return early when paused (leaving last frame). Also keep controls responsive.

Controls: HTML buttons overlaid. Pause/Resume toggles label. Restart button.

Also maybe show particle count / fps info (optional).

Canvas fit viewport: createCanvas(windowWidth, windowHeight), pixelDensity(min(2, displayDensity)) maybe 1 for perf. Use pixelDensity(1) for perf with 3000 particles? Higher density makes trails nicer. Let's use pixelDensity(Math.min(2, window.devicePixelRatio||1)) — canvas backing store scaled. Performance with fillRect over full screen at 2x each frame — fine.

Note: the runner viewport is 1200x800.

Also ensure background resize: on windowResized, resizeCanvas and clear background (fill with bg) — trails lost, acceptable.

Important: p5 global mode with `setup`, `draw` defined at top level.

Let's also guard: reduce particle count if window very small? Keep fixed 3000.

Color palette: hue base ranges — maybe two-tone palette: cyan/blue to magenta/orange. Use hsl via colorMode(HSL, 360,100,100,100)? But I'm drawing with ctx directly using hsla strings — simpler: compute `hsla(h, 80%, 60%, a)` strings.

Let's do direct ctx for particle drawing, and p5 for background/noise/setup. Actually we can do everything with p5's drawingContext.

Fade implementation: each frame:
```
const ctx = drawingContext;
ctx.globalCompositeOperation = 'source-over';
ctx.fillStyle = `rgba(${bg},${bg},${bg},${fadeAlpha})`;
ctx.fillRect(0,0,w,h);
ctx.globalCompositeOperation = 'lighter';
... draw lines per bucket ...
ctx.globalCompositeOperation = 'source-over';
```
Where bg ~ 8 (dark). fadeAlpha ~ 0.08-0.15 → trail length. With 60fps, alpha 0.1 gives short trails (~30 frames). Let's use 0.06 for longer trails, or 0.09.

Wait: with translucent black fade, dark background approaches bg color asymptotically — fine.

Performance test needed. 3000 line segments per frame with batching by bucket: 12 buckets → 12 strokes. Very fast.

Buckets: NB = 16 hue buckets? Colors vary over time smoothly if bucket assignment changes as shift increases — yes hue drifts.

Color design: each particle has baseHue in a palette range. Let's give palette: hues spanning 160-320 (cyan→magenta) plus some 20-50 (amber) — bimodal. Or simply full spectrum drift. Let's do: base hue random from a set of palette anchors with spread, e.g., anchors [190, 210, 280, 320, 30, 50] with ±20 spread. Then global shift over time = t*8 degrees/s.

For bucket batching: bucket = floor((((baseHue + shift) % 360) + 360) % 360 / (360/NB)). With NB=36 → 10° buckets, stroke color = bucket center hue. Lightness/alpha can vary per particle? Keep per-bucket constant alpha (e.g., 0.5) with lighter blending.

Hmm but particle-specific variation in alpha would break batching. Fine — vary alpha by bucket: some buckets dimmer. Or vary line width per bucket (1–1.6).

To add per-particle variation without breaking batching, we can sort particles by bucket each frame? No — instead sort by baseHue once at init; as shift grows uniformly, bucket ordering by (base+shift) mod 360 remains sorted up to wrap. So runs are contiguous: iterate sorted order, compute bucket, start new path when bucket changes (including wrap). That handles all particles, ordering by color naturally. 

Also color variation over time — yes shift.

Additionally, maybe make hue depend on particle speed or field angle: hue = base + shift + k*angle? That would break sorting. Keep it simple: hue = base + shift + small per-particle phase (already in base).

Alternatively color by position (like hue = (x/w)*something + shift)? Then batching by hue buckets requires re-sorting. Keep base-hue sorted approach.

Hmm, but "vary particle colors over time" — global shift does that. Also could modulate lightness over time per bucket. Good.

Additional idea: recycle events give particles new base hue? That breaks sort order. Instead, keep base hue fixed per particle (assigned at init, sorted). On recycle, position changes only. Restart re-randomizes bases and re-sorts. Good.

Now let's think about "nearby particles follow locally coherent directions" — with field scale ~0.0015 and angle from noise*TAU*2, coherence region maybe ~1/0.0015 = 600px... let's use scale 0.0025 for visible swirls at 1200x800.

Speed: 1.2–2.0 px/frame.

Also add slight curliness: angle from noise with 2 octaves.

dt handling: use frameRate-independent stepping: use delta time from millis, clamp. Simplicity: fixed per-frame step, assume ~60fps. But to be safe, scale by delta/16.67 clamped to [0.5, 2]. And field time advance uses dt too. Let's include `dtFactor = constrain(deltaTime/16.667, 0.25, 3)`.

But pause: p5 keeps calling draw; when paused, we skip updating and skip fading (so frame stays). Need to avoid drawing anything. Just `if (paused) return;` at top of draw. Good — canvas retains last frame.

Restart while paused: should clear and re-init; then it's paused showing new arrangement. Fine — maybe auto-resume? Keep as is: restart re-inits and clears trails; if paused, still shows new arrangement (static). Test will restart probably while running.

Trail clear on restart: fill full opaque background.

Also "Avoid allocating an ever-growing trail history" — we only use canvas fade. Good.

Also maybe add a subtle "flow field visualization"? Not required.

Info display: show particles count, fps, paused state. Nice-to-have.

Also add keyboard: space toggles pause, R restarts. Optional.

Now DOM controls: fixed top-left or bottom-center panel with buttons styled. Must be responsive at 1200x800. Use a flex container, backdrop blur, etc. Buttons handle clicks (pointer events over canvas fine).

Let's also handle `windowResized`.

Edge: p5 global mode attaches to body; canvas fills. Use CSS: `html,body{margin:0;overflow:hidden;background:#05060a;}` and `canvas{display:block;}`.

Buttons: place at top-left with pointer-events auto.

Now write code.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Flow Field</title>
<style>...</style>
</head>
<body>
<div id="ui">...</div>
<script src="p5.min.js"></script>
<script>
let particles = [], order = [], W=0,H=0;
const COUNT = 3000;
const FS = 0.0026;       // field spatial scale
const SPEED = 1.6;
const NB = 36;           // hue buckets
const HUE_SPAN = 360/NB;
let fieldT = 0;
let paused = false;
let seedVal = 1;
const anchors = [185, 200, 215, 275, 300, 320, 25, 45];
...
```

Particle representation: use parallel typed arrays for performance: px, py (prev x/y), x, y, hue, plus sorted order array (Int32Array). Typed arrays avoid allocation. Let's do Float32Array(COUNT) for each.

setup():
```
function setup(){
  createCanvas(windowWidth, windowHeight);
  pixelDensity(Math.min(2, window.devicePixelRatio || 1));
  frameRate(60);
  initParticles(true);
}
```

initParticles(newColors): assign positions random, hues random around anchors, order = indices sorted by hue.

Sorting: build array of indices, sort by hue. Int32Array from sorted array.

Actually we don't even need sorting if we compute bucket and just start a new path whenever bucket changes — but unsorted particles would create COUNT paths (worst case), killing perf. So sort.

But note: after sorting, particle i order fixed; buckets change with shift but relative order preserved. 

Draw:
```
function draw(){
  if (paused) return;
  const dt = constrain(deltaTime/16.667, 0.25, 3);
  update(dt);
  render();
}
```

update: fieldT += 0.0006*dt... Actually noise z advances; the angle also depends on t directly. Let's define fieldT += 0.15 * dt * 0.01 → too slow? Choose: per second, z advances 0.06 (so full decorrelation over ~a few seconds to a minute). Perlin noise decorrelates over ~1 unit in z roughly (actually features ~0.5-1 unit). 0.06/s → visible evolution over ~8-16s. Let's use 0.05/s.

Speed: pos += cos(angle)*SPEED*dt, sin*.

Recycle: if x < -10 || x > W+10 || y < -10 || y > H+10 → respawn random within [0,W]x[0,H]. Note particles might get stuck in spiral centers (fixed points) — add tiny jitter and also lifetime-based recycle: give each particle a life counter; when life exceeds maxLife (e.g., 200-500 frames), respawn. That prevents stagnation and keeps motion lively. Life stored in Int32Array.

Render as described.

Let's think about trails + fade alpha: fadeAlpha = 0.10. Trail length: a pixel brightness decays by 0.9 per frame → after 30 frames ~4%. With speed 1.6px/frame, trail ~45px. Good.

Let's also add slight per-bucket lightness variation over time: lightness 55 + 15*sin(fieldT*0.5 + b). Optional, adds color variety.

hueShift over time: hueShift = (frameCount * 0.06 * dt?) — better: accumulate `hueShift += 6 * dtSeconds`. dt in frames: dtSeconds = dt/60. hueShift += 6 * (dt/60) → 6 degrees/sec. Also add global variation tied to fieldT maybe. Fine.

Bucket color: hsl(hue, 85%, 60%) with alpha 0.45 → in 'lighter' mode.

Wait: alpha with 'lighter' — source alpha scaled adds. Fine.

Also we could modulate particle hue by angle at init only... skip.

Also color variation over time could additionally come from lightness oscillation per bucket. Good.

Restart function:
```
function restart(){
  fieldT = random(1000); // or keep counter
  hueShift = random(360);
  noiseSeed(floor(random(1e9)));
  initParticles(true);
  fillBackground(true);
}
```
Actually noiseSeed random ensures new arrangement. Also position randomness already gives new arrangement; noiseSeed makes field different too.

fillBackground: ctx composite source-over, fillStyle rgb(bg), fillRect.

Also on resize: resizeCanvas + fillBackground (clears trails) and keep particles (clamp positions). Fine.

Buttons:
- #btnPause: toggles paused, text Pause/Resume.
- #btnRestart.
- maybe a counter showing "3000 particles".

Also info: FPS display updated every 30 frames (DOM update). Might cause layout thrash; update every 500ms.

Let me write it.

Careful with p5 global functions and `drawingContext` — available in global mode as `drawingContext`.

One more: to ensure nearby coherence and visible structure, angle mapping: 
```
function flowAngle(x, y){
  const n1 = noise(x*FS, y*FS, fieldT);
  const n2 = noise(x*FS*2.3 + 100, y*FS*2.3 + 100, fieldT*1.3 + 50);
  return (n1*0.75 + n2*0.25) * TWO_PI * 2;
}
```
noise() call cost: 2 per particle per frame = 6000 noise calls/frame — p5 noise is fairly fast (simplex-ish/perlin). Might be OK but let's measure. Alternative: sample the field on a coarse grid (e.g., 40x30 cells) each frame and bilinearly interpolate per particle — much faster and still smooth. But requirement says "motion guided by a smoothly varying Perlin-noise vector field" — computing noise on grid is still Perlin-derived. Sampling grid: cell size 40px → 1200/40=30 x 800/40=20 = 600 cells × 2 noise calls = 1200 noise calls per frame. Then bilinear interpolate per particle. That's much cheaper. But interpolation adds complexity; also grid must be recomputed each frame (field evolves). 

Let's first try direct per-particle noise with 1 noise call (single octave) and measure fps. If good, maybe use 2 octaves. p5 noise ~ maybe 0.5µs each → 3000 calls = 1.5ms. Fine actually. Let's do 2 calls = 6000 → 3ms. Acceptable. I'll test with fps display.

Actually p5's noise is implemented in JS with gradient tables — reasonably fast. Let's benchmark in the browser.

Alternatively implement my own Perlin (faster, and gives me 4D-ish control). But p5 noise is fine and clearly "Perlin-noise". Let's test performance.

Let's write the file now.

Additional detail: to keep nearby particles coherent but avoid all particles collapsing, add small random perturbation? Not needed.

Also "Recycle particles at the canvas boundaries and keep the population bounded" — constant COUNT, respawn at bounds and on life expiry. Good.

Let me write code carefully.

```js
const COUNT = 3000;
const MAX_LIFE = 420; // frames

let px, py, cx, cy, life, hueBase;
let order;      // Int32Array sorted by hueBase
let W, H;
let paused = false;
let hueShift = 0;
let fieldT = 0;
let bgRGB = [6, 8, 14];

function setup() {
  const c = createCanvas(windowWidth, windowHeight);
  c.style('display','block');
  pixelDensity(Math.min(2, (window.devicePixelRatio||1)));
  background(bgRGB[0], bgRGB[1], bgRGB[2]);
  alloc();
  restart();
}
```
Careful: background() from p5 with rgb — p5 default rgb max 255, so background(6,8,14) works.

alloc(): create typed arrays.

respawn(i, initial): random pos; if not initial, also random pos (anywhere). prev = pos.

Sorting after hues assigned (only on restart/init).

update(dt):
```
fieldT += 0.05 * (dt/60);
hueShift = (hueShift + 7 * (dt/60)) % 360;
for i in 0..COUNT:
  const a = flowAngle(cx[i], cy[i]);
  let nx = cx[i] + Math.cos(a)*SPEED*dt;
  let ny = cy[i] + Math.sin(a)*SPEED*dt;
  px[i]=cx[i]; py[i]=cy[i]; cx[i]=nx; cy[i]=ny;
  life[i]++;
  if (nx<-8||nx>W+8||ny<-8||ny>H+8||life[i]>MAX_LIFE) respawn(i,false);
```
Note life reset in respawn.

Also speed variation per particle? Could multiply SPEED by (0.6+0.8*rand) stored per particle — adds richness. Store `spd` Float32Array. Yes.

render(dt): fade + draw.

Draw loop with batching:
```
const ctx = drawingContext;
ctx.globalCompositeOperation='source-over';
ctx.fillStyle = `rgba(${r},${g},${b},${FADE})`;
ctx.fillRect(0,0,W,H);
ctx.globalCompositeOperation='lighter';
ctx.lineCap='round';
let curB=-1, hue;
for (let k=0;k<COUNT;k++){
  const i = order[k];
  hue = hueBase[i] + hueShift;
  hue = ((hue % 360)+360)%360;
  const b = (hue / HUE_SPAN) | 0;  // 0..35
  if (b !== curB) {
    if (curB !== -1) ctx.stroke();
    curB = b;
    ctx.beginPath();
    ctx.strokeStyle = `hsla(${(b+0.5)*HUE_SPAN}, 85%, ${60+8*Math.sin(...)}%, 0.5)`;
    ctx.lineWidth = ...;
  }
  ctx.moveTo(px[i], py[i]);
  ctx.lineTo(cx[i], cy[i]);
}
if (curB !== -1) ctx.stroke();
```
Wait — the modulo wrap in hue: hueBase sorted ascending, +hueShift then mod → order preserved as cyclic, buckets contiguous with a wrap point. Since we detect bucket change and restart path, that's handled: the wrap point creates one extra path. 

But careful: computing `hue` per particle requires modulo per particle — cheap.

Edge: pixelDensity scaling — drawingContext is scaled by p5's transform? p5 sets ctx scale by pixelDensity at start of each frame (in background/draw cycle?). p5 applies `this._renderer.drawingContext.scale(p, p)` in `background`? Actually p5 redraws resetTransform then scales by pixelDensity each draw call start (in `_draw`?). In p5 1.x, `p5.Renderer2D.prototype.beginScratch`... Hmm. Let me recall: p5's `redraw()` calls `this._renderer.beginDraw?` Actually the transform with pixelDensity: p5 sets `ctx.scale(pd, pd)` inside `background()`? No.

In p5.js, `p5.Renderer2D.prototype._applyTextProperties`... Let me think: p5 stores drawingContext with a persistent transform? In p5 1.x source, `Renderer2D.prototype.resizeCanvas` sets `this.drawingContext.setTransform(1,0,0,1,0,0)` and applies... Hmm. Actually p5 applies pixelDensity via `this.drawingContext.scale(p, p)` in `p5.Renderer2D.prototype.background`? No.

Better: I recall p5 applies pixel density scaling in `p5.prototype.redraw` → `this._renderer.clear?`... Let me just check the source with grep.

Also `background()` in p5 clears using ctx.fillRect with transform applied. Safest: in my render, use `ctx.save(); ctx.setTransform(pd,0,0,pd,0,0)` — but if p5 already scaled, that would double. Safest: use `ctx.getTransform()` and operate in the current transform (which is what p5 uses for background), so my fillRect(0,0,W,H) matches. Since I never call push/pop or translate, the current transform during draw should be whatever p5 set (density scale). So just draw in the same space as p5 drawing — coordinates in CSS pixels. That should match `background()` behavior. Also `resetMatrix()` not called by me.

But one caveat: p5 might reset the transform at the start of each draw frame (in `redraw`), applying density scale. As long as I don't change it, fine. I'll avoid save/restore too? save/restore is balanced so fine.

Let me grep p5.min.js for how density transform applied... it's minified but I can search for `setTransform`. Not worth it; test empirically: draw a line from (0,0) to (100,100) and compare with background covering full canvas. I'll visually verify via screenshot.

Actually a robust approach: don't rely on the transform; instead compute `const t = ctx.getTransform(); const pd = t.a;` then fillRect(0,0,W,H) works if t is scale(pd). Simply use current transform and CSS-pixel coordinates — consistent with p5's own drawing (background, rect). I'll trust that.

Hmm, but if p5 does NOT scale the context (instead uses canvas width = W*pd and no scale, drawing in device pixels where coordinates must be multiplied)... p5 does scale: it sets `this.drawingContext.scale(pd,pd)` after resize (I'm fairly confident p5 1.x applies pixel density scaling in resizeCanvas). Let's verify empirically with a screenshot: background should cover whole canvas (if not, we'd see partial clearing). background() in p5 fillRect(0,0,width,height) in the same transform as mine, so both consistent anyway.

Actually there's one known subtlety: p5's `background()` uses `this.drawingContext.fillRect` after possibly `clearRect` with same transform. Since I use the same transform, consistent.

Fade approach: instead of fillRect with rgba each frame (which needs correct transform), could use p5's `background(r,g,b,a)` with alpha — p5 supports alpha in background (it does `fill` + `rect` or clearRect... p5 background with alpha: for 2D it does `ctx.fillStyle=rgba; fillRect` I think? Actually p5's background with alpha does `clearRect` then fill with alpha? There is special handling: "background with alpha" in p5 uses `this._renderer.background` which does `ctx.fillStyle=...; ctx.fillRect` only if alpha===255 else it does clearRect+fillRect? I recall p5 background with alpha doesn't composite over previous content properly... hmm, p5 does handle it: `if (a < 255) { ctx.clearRect... }`? Not sure. Safer to do my own fillRect on drawingContext. Since alpha fade with clearRect would erase trails entirely.

Hmm, but there's a risk: if p5's background() clears the canvas at start of each frame (some modes do). In 2D canvas, p5 does NOT clear automatically each frame (that's why trails work in p5 examples). Good.

Now, DOM UI must be above canvas: canvas is appended to body; UI div with position:fixed; z-index.

Also `overflow:hidden` on body.

Let's write the file.

Also add a small legend/instructions: "Space: pause • R: restart".

Also maybe show FPS. Let's include: `<span id="stat">3000 particles • 60 fps</span>`.

Write code now.

Potential issue: p5's `noise()` uses `noiseSeed`. Fine.

Also `random()` global from p5 available in global mode.

Regarding performance: `Math.cos/sin` per particle: 6000 trig calls → fine.

flowAngle: 2 noise calls per particle = 6000/frame. Let's test fps; if low, reduce to 1 noise call.

Alternative for coherence: cache per-cell? Let's just test.

Now Restart: "Restart clears trails and initializes a new particle arrangement." Implement:
```
function restart(){
  noiseSeed(Math.floor(random(1000000)));
  fieldT = random(0, 500);   // different field phase
  hueShift = random(0,360);
  assignHues(); // randomize
  sortOrder();
  for i: respawn(i, true);
  clearTrails(); // opaque fill
  paused stays? Keep paused state unchanged.
}
```

Note: after restart, first draw frame will also fade with FADE alpha — negligible since background is opaque-ish (fade alpha just slightly lightens/darkens toward bg). Actually fade fill with rgba(bg, 0.1) over bg → stays bg. Fine.

Hmm — but with 'lighter' compositing left over? I reset composite each frame. Make sure to reset after drawing.

Also to be safe set `ctx.globalAlpha = 1`.

Let's write.

For the fade, maybe make fade alpha vary slightly: constant is fine.

Colors: buckets 36 → hsla with hue (b+0.5)*10.

Lightness per bucket varies over time: `58 + 10*Math.sin(b*0.7 + fieldT*1.5)`.
Alpha: `0.55` fixed? With lighter blending and 3000 segments, overlapping → bright. Let's use 0.45 and lineWidth 1.1.

Let's write the HTML.

Also handle window resize: `windowResized()` → resizeCanvas(width,height); W,H update; clearTrails().

Store W = windowWidth? use `width`/`height` p5 globals after resize; but typed arrays independent. I'll keep module-level W,H updated in a function `syncSize()`.

Also visibility change: if tab hidden, deltaTime huge → clamp handles.

Also p5 `deltaTime` on first frames maybe 0 → clamp min 0.25.

Write file.

For UI buttons: styled with CSS, flex row, gap. Also a title.

Let me write now.

```html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8"/>
<meta name="viewport" content="width=device-width,initial-scale=1"/>
<title>Flow Field · Perlin particle streams</title>
<style>
  :root{--panel:rgba(10,12,20,.62);}
  *{box-sizing:border-box}
  html,body{margin:0;padding:0;width:100%;height:100%;overflow:hidden;background:#05070d;}
  body{font-family:ui-sans-serif,system-ui,-apple-system,"Segoe UI",Roboto,Helvetica,Arial,sans-serif;color:#e8ecff;}
  canvas{display:block;position:fixed;top:0;left:0;}
  #ui{position:fixed;top:14px;left:14px;z-index:10;display:flex;flex-direction:column;gap:10px;max-width:calc(100vw - 28px);}
  .panel{display:flex;align-items:center;gap:10px;flex-wrap:wrap;background:var(--panel);backdrop-filter:blur(10px);border:1px solid rgba(140,170,255,.18);border-radius:12px;padding:10px 12px;box-shadow:0 8px 30px rgba(0,0,0,.45)}
  .title{font-size:13px;letter-spacing:.16em;text-transform:uppercase;color:#9fb4ff;font-weight:600}
  button{font:inherit;font-size:13px;font-weight:600;color:#e9edff;background:linear-gradient(180deg,rgba(70,90,160,.55),rgba(40,52,110,.55));border:1px solid rgba(150,180,255,.3);border-radius:9px;padding:8px 14px;cursor:pointer;transition:.15s;white-space:nowrap}
  button:hover{background:linear-gradient(180deg,rgba(95,120,210,.7),rgba(55,70,140,.7));border-color:rgba(180,205,255,.55);transform:translateY(-1px)}
  button:active{transform:translateY(0)}
  button:focus-visible{outline:2px solid #8fb4ff;outline-offset:2px}
  .stat{font-size:12px;color:#a9b6e6;font-variant-numeric:tabular-nums}
  .hint{font-size:11px;color:#7d8ac0}
  .dot{width:8px;height:8px;border-radius:50%;background:#59f2a8;box-shadow:0 0 8px #59f2a8;display:inline-block;margin-right:6px}
  .dot.paused{background:#ffd166;box-shadow:0 0 8px #ffd166}
</style>
</head>
<body>
<div id="ui">
  <div class="panel">
    <span class="title">Flow Field</span>
    <button id="btnPause" type="button" aria-pressed="false">Pause</button>
    <button id="btnRestart" type="button">Restart</button>
    <span class="stat"><span id="stateDot" class="dot"></span><span id="stateTxt">running</span></span>
  </div>
  <div class="panel hint"><span id="stat">—</span></div>
</div>
<script src="p5.min.js"></script>
<script>
...
</script>
</body>
</html>
```

Now the JS.

```js
const COUNT = 3000;
const SPEED = 1.7;
const FIELD_SCALE = 0.0026;
const MAX_LIFE = 480;
const FADE = 0.10;
const NB = 36;
const HUE_SPAN = 360 / NB;
const BG = 'rgba(5,7,13,';

let X, Y, PX, PY, HUE, SPD, LIFE, ORDER;
let W = 0, H = 0;
let paused = false;
let fieldT = 0, hueShift = 0;
let statTimer = 0;

const ANCHORS = [186, 198, 210, 226, 272, 288, 306, 322, 24, 40];

function setup() {
  createCanvas(windowWidth, windowHeight);
  pixelDensity(Math.min(2, window.devicePixelRatio || 1));
  W = width; H = height;
  alloc();
  restart();
}
```
Note: `width`,`height` set after createCanvas.

alloc(): 
```js
function alloc(){
  X = new Float32Array(COUNT); Y = ...; PX, PY, HUE, SPD, LIFE = new Int32Array(COUNT), ORDER = new Int32Array(COUNT);
}
```

respawn(i, anywhere):
```js
function respawn(i, anywhere){
  X[i] = random(0, W); Y[i] = random(0, H);
  PX[i] = X[i]; PY[i] = Y[i];
  LIFE[i] = 0;
  SPD[i] = 0.55 + random(0.95);   // speed multiplier 0.55..1.5
}
```
Hmm "recycle at boundaries": respawn anywhere is fine (respawn at boundary maybe nicer: spawn just inside an edge with inward velocity? "Recycle particles at the canvas boundaries" means when they leave, they're recycled). Random anywhere is fine, but spawning just inside the edge where they exited gives nice continuous streams. Let's do: on boundary exit, respawn at the edge they crossed (inside, with small random offset along edge). On life expiry, respawn anywhere. That looks good: streams keep flowing from edges.

Implement respawn(i, mode): mode 'edge' with last direction: we know exiting side from coords.

```js
function respawnEdge(i){
  let x = X[i], y = Y[i];
  if (y <= -8) { y = 2; x = random(W); }
  else if (y >= H+8) { y = H-2; x = random(W); }
  else if (x <= -8) { x = 2; y = random(H); }
  else { x = W-2; y = random(H); }
  ...
}
```
Careful: if both out, pick by larger violation. Simpler: handle in order with else-if. Fine.

Then LIFE reset to a partial value? Reset 0.

sort: ORDER = indices sorted by HUE.

```js
function buildOrder(){
  const idx = new Int32Array(COUNT) ... // need array for sort
  const arr = Array.from({length:COUNT},(_,i)=>i);
  arr.sort((a,b)=>HUE[a]-HUE[b]);
  ORDER.set(arr);
}
```
Array allocation only at restart — fine (bounded).

restart():
```js
function restart(){
  noiseSeed(Math.floor(random(1e9)));
  fieldT = random(0, 400);
  hueShift = random(0, 360);
  for (let i=0;i<COUNT;i++){
    HUE[i] = ANCHORS[(Math.random()*ANCHORS.length)|0] + random(-14,14) ... use p5 random
  }
  buildOrder();
  for i: respawnAnywhere(i);
  clearField(); // opaque fill
}
```
Wait: HUE must be in [0,360); anchors include 24,40 with -14 → 10 fine.

draw():
```js
function draw(){
  updateStats();
  if (paused) return;
  const dt = constrain(deltaTime / 16.6667, 0.2, 3);
  step(dt);
  render(dt);
}
```
Careful: if paused, we return before render — canvas keeps last frame. Good. But stats should still update? Fine either way.

step(dt):
```js
function step(dt){
  fieldT += 0.055 * (dt/60);
  hueShift = (hueShift + 6 * (dt/60)) % 360;
  const adv = SPEED * dt;
  for (let i=0;i<COUNT;i++){
    const x = X[i], y = Y[i];
    const a = flowAngle(x,y);
    const nx = x + Math.cos(a) * adv * SPD[i];
    const ny = y + Math.sin(a) * adv * SPD[i];
    PX[i]=x; PY[i]=y; X[i]=nx; Y[i]=ny;
    LIFE[i]++;
    if (nx < -8 || nx > W+8 || ny < -8 || ny > H+8) respawnEdge(i);
    else if (LIFE[i] > MAX_LIFE) respawnAnywhere(i);
  }
}
```

flowAngle:
```js
function flowAngle(x,y){
  const n1 = noise(x*FIELD_SCALE, y*FIELD_SCALE, fieldT);
  const n2 = noise(x*FIELD_SCALE*2.1 + 37.5, y*FIELD_SCALE*2.1 + 91.3, fieldT*1.4 + 20);
  return (n1*0.72 + n2*0.28) * TWO_PI * 2.2;
}
```
Hmm, with multiplier 2.2, angle range 0..4.4 TAU — a bit wild but noise is smooth spatially so still coherent. Multiplier 2 gives up to 2 full rotations across the noise range; gradients... Coherence depends on spatial gradient of angle: d(angle)/dx = dnoise/dx * 4π rad. noise gradient magnitude ~ (1 unit of noise change per 1/FIELD_SCALE pixels)... With FIELD_SCALE 0.0026, over 100px noise argument changes 0.26 → noise changes maybe ~0.1-0.2 → angle changes 0.15*4π ≈ 1.9 rad over 100px. Reasonable coherence. But with 2 octaves adding higher frequency it'll be wigglier. Maybe use multiplier 1.6 and n2 weight 0.25. Let's use `(n1*0.75 + n2*0.25) * TWO_PI * 1.8`. Tune visually.

render(dt):
```js
function render(){
  const ctx = drawingContext;
  ctx.globalCompositeOperation = 'source-over';
  ctx.globalAlpha = 1;
  ctx.fillStyle = BG + FADE + ')';
  ctx.fillRect(0,0,W,H);
  ctx.globalCompositeOperation = 'lighter';
  ctx.lineCap = 'round';
  ctx.lineJoin = 'round';
  let curB = -1;
  for (let k=0;k<COUNT;k++){
    const i = ORDER[k];
    let h = HUE[i] + hueShift;
    h = h >= 360 ? h - 360 : h;   // HUE<360 and hueShift<360 so h<720, one subtraction enough
    const b = (h / HUE_SPAN) | 0;
    if (b !== curB){
      if (curB !== -1) ctx.stroke();
      curB = b;
      ctx.beginPath();
      const hue = (b + 0.5) * HUE_SPAN;
      const light = 56 + 12 * Math.sin(fieldT * 2.0 + b * 0.55);
      ctx.strokeStyle = 'hsla(' + hue.toFixed(1) + ',90%,' + light.toFixed(1) + '%,0.42)';
      ctx.lineWidth = 1.15;
    }
    ctx.moveTo(PX[i], PY[i]);
    ctx.lineTo(X[i], Y[i]);
  }
  if (curB !== -1) ctx.stroke();
  ctx.globalCompositeOperation = 'source-over';
}
```
Note HUE[i] could be 359.x and hueShift 359.x → sum 718.x → subtract 360 → 358.x ok; but if HUE max ~360? anchors max 40+14=54, min 186-14=172... anchors: 186..326 and 24,40 → ranges fine, all within 10..340. So sum < 700. One subtraction suffices; still use modulo-safe while loop or ((h%360)+360)%360 for safety. Cheap enough (3000 modulo ops fine).

Note: PATHS break when bucket changes — with sorted HUE and uniform shift, buckets are non-decreasing except at wrap → at most NB+1 paths per frame. 

Also: since SPD affects length, and resume after pause: on resume, PX,PY still equal X,Y from last step (we set them each step), so no giant jump. Good — as long as we don't move particles while paused. Right.

But careful: on resume after a long pause, deltaTime will be huge (p5 deltaTime accumulates since last draw? p5 resets deltaTime each draw cycle? p5's deltaTime is time since last frame — computed in the loop, so after pause we return early but the loop still runs each frame, so deltaTime stays ~16ms. Actually if browser tab hidden, p5 loop pauses and deltaTime jumps on return. Clamp handles it.

stats update: every 250ms update DOM with fps and count.

Also handle `noSmooth`? Not needed.

Also p5 might complain about `background` — I use ctx directly; fine.

Restart button also should reset `PX,PY` (done in respawn).

Also `windowResized`:
```js
function windowResized(){
  resizeCanvas(windowWidth, windowHeight);
  W = width; H = height;
  clearField();
}
```
Particles outside will recycle next step.

clearField(): opaque fill.

Also initial: restart() called in setup calls clearField — need drawingContext ready; it is after createCanvas.

Potential issue: p5 `pixelDensity` must be called before/after createCanvas? Calling after createCanvas triggers resize of the canvas backing store — p5 supports pixelDensity(num) after createCanvas (it calls this._pixelDensity and resizes). Standard examples: `createCanvas(...); pixelDensity(1);` — yes, works.

Hmm, actually careful: setting pixelDensity after createCanvas in p5 1.x: `p5.prototype.pixelDensity = function(d){ this._pixelDensity = d; ... if(this._renderer) resizeCanvas(...) }`. I believe it applies. To be safe, call `pixelDensity(...)` before createCanvas? In p5, pixelDensity before createCanvas also works (stored on instance). Examples often put it right after createCanvas. I'll put it right after createCanvas and verify visually that the canvas fills the screen (device pixel ratio in headless browser is likely 1 anyway).

Test plan with browser tool:
1. open, screenshot at t0, t1, t2 — check trails and coherence.
2. Click Pause → screenshot twice → frames identical (verify via evaluating? browser tool gives screenshots; I can compare visually or use JS evaluation... The browser tool has "inspect" action which may show console/DOM. There's no direct evaluate action listed; actions: reload, inspect, screenshot, motion, click, drag, key, type, scroll. "inspect" probably dumps DOM/console. Motion takes frames over time? I'll use screenshots.

To verify pause freezes: take screenshot, wait, screenshot again, compare visually (identical patterns). I can also compute a hash by... no evaluate tool. Hmm, maybe `inspect` returns console output including logs. I could add a debug hook: log frame signature to console when button clicked (e.g., `console.log('paused at', frameCount)`). Then inspect console. Better: I can add a small dev-only instrumentation? Not necessary to keep in final file... but harmless. Actually I can verify freeze by screenshots (trails pattern would visibly change otherwise). Visual comparison of two screenshots should be evident — the flow pattern changes noticeably over 1-2 s.

For verifying "new arrangement after restart": screenshot before restart and after — positions differ. Since trails clear, the first frame after restart shows only fresh short segments (nearly invisible!) — after restart, trails cleared and particles start drawing new short lines. So screenshot right after restart shows sparse dots/short streaks, then grows. That's expected and demonstrates trail clearing.

Let me also make sure that on restart while running, immediately after we see near-empty canvas then trails rebuild — good visual proof.

One concern: with FADE 0.10 and 'lighter', initial screen after restart: particles draw 1-frame segments of length ~1.7px — looks like faint dots. Then within ~1s trails appear. Fine.

Maybe increase initial visibility: nothing needed.

Let's write the file and test.

Also: to show "changing colors over time", hueShift 6°/s → 60° in 10s. Visible. Also lightness oscillation with fieldT.

Also I might add slight per-particle hue breathing: h = HUE[i] + hueShift + 8*sin(fieldT*3 + i*0.01)? That breaks sort ordering slightly (bucket ordering could interleave). Deviation 8° vs bucket 10° → could cause many bucket changes → many paths. Avoid. Keep uniform shift.

Hmm, but I want more color dynamics. Alternative: also make the lightness/alpha vary over time (already do with fieldT). Good.

Let's write it.

One more requirement: "Animate at least 2,000 particles" — COUNT 3000. Maybe scale count with area? Keep 3000 fixed (bounded population).

Performance check: I'll log fps in stats panel.

Write the file.