Matrix digital rain · laguna-s-2.1

Let me build a full-screen Matrix-style digital rain effect in a single self-contained index.html file. Let me plan this out carefully.

I need:
1. Full-screen black canvas
2. Multiple columns of green katakana glyphs
3. Each column has a brighter leading character and fading trail
4. Columns move independently at different speeds and start positions
5. Recycle columns after they leave the bottom
6. Pause/Resume and Restart controls
7. Resize handling
8. No external resources - purely local

Let me write this carefully. I'll use a canvas element, draw glyphs procedurally, use Katakana characters.

Let me think about the structure:
- HTML body: fullscreen, black background
- A canvas that fills the viewport
- UI controls for Pause/Resume and Restart (could be overlaid buttons)
- CSS in style tag
- JS in script tag

For the animation:
- Columns calculated based on canvas width / character width
- Each column has: x position, y position (current), speed, and a list of recent glyphs with their alpha (for trail)
- Actually, a common approach: each column has a y offset that advances, and we draw glyphs at each position. The leading glyph is bright, trailing ones fade.

Let me think about how to implement the trail effect:
- For each column, I can keep track of a list of glyph positions with timestamps or indices
- Or simpler: draw glyphs at intervals along the column. The glyph at the current position (top of the moving part) is bright white/green, and glyphs below it fade based on distance.

A clean approach:
- Each column has a `y` position (the offset that moves down)
- We draw a glyph at each row position from the column's current y downward, with decreasing opacity the further down we go
- The leading glyph (at the top, y position) is full brightness
- Actually in matrix rain, the leading character is the brightest, and it leaves a trail that fades as it goes down. So the top of the column (the moving front) is bright, and behind it trails fade.

Let me reconsider. In matrix rain:
- Characters fall from top to bottom
- The leading character is bright
- Behind it, characters fade out (trail gets dimmer the further from the head)

So for each column, I track a y position (the head). I draw glyphs along the column: a string of glyphs. The glyph at the head y is brightest. Glyphs below the head (already passed) are the trail, fading.

One approach: for each column, keep a max length (trail length in characters). Draw characters at head, head-1, head-2, ... down to some length. Each character at index i from head has alpha = brightness * (1 - i/trailLength) roughly, or exponential decay.

But each character should be a random glyph (to look like matrix). So I keep a buffer per column of recent glyphs. When the head moves down one row, I push a new random glyph at the head and the buffer shifts.

Let me do this:
- Each column has: x, y (fractional, head position moving down), speed, and an array of glyphs (the trail buffer).
- trailLength = some number like 20-30 characters
- buffer stores glyph chars, buffer[0] = head glyph (brightest), buffer[i] fades.
- On each frame: y += speed * dt. When y advances past one row, shift the buffer (add new glyph at front, pop old).
- Draw: for i in 0..buffer.length, draw buffer[i] at position y - i*charHeight with alpha = maxAlpha * decay^i.

Actually, let me keep it simpler but effective. Let me precompute the glyph buffer per column of length trailLength.

Let me think about speed variation. Each column has its own speed and charInterval.

Let me structure the data:

```
columns = []
for each column i:
  x = i * charWidth + charWidth/2
  speed = random(minSpeed, maxSpeed)  // pixels per second
  y = random(-canvasHeight, 0)  // start position varied
  buffer = array of trailLength random glyphs
  // buffer[0] is at the head
```

Per frame:
- clear canvas
- for each column:
  - y += speed * dt
  - draw buffer glyphs: for i in 0..trailLength:
    - alpha = leadingAlpha * Math.pow(decay, i)  // e.g., decay 0.95
    - draw buffer[i] at (x, y - i*charHeight)
  - if y - trailLength*charHeight > canvasHeight, reset column: y = 0 (or random near top), refill buffer
```

Hmm, but the reset condition: when the head has moved so far that the entire trail is off the bottom. Then recycle.

Actually, I want to be careful. Let me have the head at y, and trail extends from y downward (y, y+charHeight, y+2*charHeight...). Wait, which direction? In matrix, characters fall downward. The head is the topmost moving character. Below the head (higher y) are the fading trail. So trail is at y + i*charHeight for i in 1..trailLength... no wait.

Let me reconsider: the head falls down. Behind it (which is below it in screen space as it fell) is the trail. So if head is at y, trail characters are at y + charHeight, y + 2*charHeight, etc. (further down). They fade.

So:
```
draw buffer[0] (head) at y, full brightness
draw buffer[1] at y + charHeight, dim
...
draw buffer[i] at y + i*charHeight, alpha = decay^i
```

When y + trailLength*charHeight > canvasHeight, the whole column is off screen -> reset.

For the buffer: I'll shift it. When the head advances by a full char height (i.e., y crosses next multiple), I generate a new glyph for the head and push the old head down. Actually simpler: regenerate glyphs each frame isn't needed; I can just have the buffer be a fixed set that scrolls visually.

Hmm, let me think again. Let me keep a per-column glyph buffer of length trailLength. The buffer scrolls: when head moves down by one char row, shift buffer: new random glyph becomes buffer[0], others shift down, last pops off.

But to sync with pixel movement, I'll advance y in pixels and regenerate buffer entries based on how many rows the head has moved.

Let me simplify: I'll just regenerate which glyph is the "head" based on movement. Actually, a clean technique:

Each column maintains:
- `y`: fractional head position (pixels from top)
- `glyphs`: a ring buffer / array indexed by row

For drawing each row position, I can compute a glyph deterministically based on the column + row so it's stable (no need to store buffer). But the trail buffer approach with shifting is classic.

Let me just store a buffer array per column of length trailLength and shift it each time the head crosses a row boundary.

Let me track `nextHeadRow` - when floor(y/charHeight) increases, shift.

Actually, let me make each column advance by `speed * dt` in pixels, and maintain `y` fractional. The head glyph should change periodically. To keep it clean, I'll regenerate the head glyph every time y crosses a row boundary.

Let me just do: keep a `buffer` array. Each row, the head glyph is buffer[0]. I shift based on row crossings.

Let me write code:

```js
const chars = "アァカサタナハマヤラワガザダバパイィキシチニヒビピミリゥグズヅプツヅフムユルユヴザーデジボポ"
// katakana

function initColumns() {
  columns = [];
  const colsCount = Math.floor(canvas.width / charWidth) + 2; // a couple extra
  for (let i = 0; i < colsCount; i++) {
    columns.push(makeColumn(i));
  }
}

function makeColumn(i) {
  return {
    x: i * charWidth + charSize/2,
    speed: speedMin + Math.random() * (speedMax - speedMin),
    y: Math.random() * -canvasHeight * 0.8 - charSize, // varied start, some start mid-fall
    buffer: new Array(trailLength).fill(0).map(() => randomChar()),
    lastHeadRow: 0
  };
}
```

Hmm wait, x position and columns count should be based on charWidth. Let me set charSize = 24 (font size). charWidth approx 0.6*charSize.

Let me set up: fontSize = 22, charWidth = 18 (approx). Actually for monospace-ish katakana, width ~ 0.8 * fontsize. Let me measure... Katakana isn't monospace but close. I'll just use a fixed charWidth estimate, say fontSize * 0.7 = ~15 for fontSize 22. Let me compute colsCount = canvas.width / charWidth.

For drawing, I use ctx.fillText(glyph, x, y) where y is the baseline. Need to account for textBaseline = 'top' so y is top of glyph.

Let me set ctx.textBaseline = 'top', ctx.textAlign = 'center'.

For the trail alpha: leading glyph brightness ~ 0.8 (near white), decay factor per step. Let me use a base green color and vary alpha. Actually matrix uses green. Leading glyph could be brighter green (more yellow/white). I'll use fillStyle with alpha.

Let me compute for row i (i=0 is head): alpha = leadingAlpha * Math.pow(decay, i). leadingAlpha = 0.9, decay = 0.92.

Color: I'll use `hsl` or just `rgba(0, 255, 100, alpha)`. Leading could be brighter: `rgba(180, 255, 180, alpha)`.

Actually to make the leading glyph really pop, I can use a brighter green for the head specifically. Let me use:
- head: rgba(200, 255, 220, 0.95)
- trail: green with fading alpha.

Let me draw the trail in green rgba(0, 255, 120, alpha*factor).

Hmm, let me keep it consistent: one green color with varying alpha, head full brightness.

Let me now think about the head glyph regeneration. I'll track headRow = floor(col.y / charHeight). When it changes, shift buffer and add new glyph. Actually simpler: every frame, I just need the head to be a "fresh" bright glyph. But to make trail glyphs stable (not flickering each frame), I should store the buffer.

Let me reconsider: I keep `buffer` of length trailLength. buffer[0] is head. When the head moves down by a full charHeight (one row), I do buffer.unshift(newRandomChar()) and buffer.pop(). This keeps stable glyphs per cell. And `lastHeadRow` tracks last shift.

But there's subtlety: the head position y is fractional. The shift should happen when crossing row boundaries. Let me track: each frame compute headRow = Math.floor(col.y / charHeight). If headRow > col.lastHeadRow, shift (headRow - col.lastHeadRow) times. Update lastHeadRow.

Wait, but then the buffer[0] is at y aligned to... Let me think. The visual: head at y (top). buffer[i] at y + i*charHeight. The buffer glyphs were shifted when crossing rows. When I unshift a new glyph for the head, that glyph stays at buffer[0] until next row crossing. Good. That gives a stable head glyph that changes every row. 

But actually the head glyph changing every row (every charHeight / speed time) might be too slow/odd. It's fine - matrix characters do cycle. Let me make head glyph cycle fast - regenerate every row is okay, or I could regenerate the head more frequently. Let me just regenerate on row crossings; it looks fine.

Hmm, actually wait. There's a subtlety with the recycling. When column y + trailLength*charHeight > canvas.height + some margin, reset: y = -charSize (or random near top), refill buffer.

Let me handle recycling: after updating y, check if head is past bottom enough. `if (col.y - charHeight > canvas.height) resetColumn`. Actually reset when the tail (y + trailLength*charHeight) is well below bottom. Let me reset when col.y > canvas.height + charHeight. On reset, set y = Math.random() * -canvasHeight*0.5 - charSize (varied re-entry), refill buffer with random chars.

Wait, but y being negative means head starts above viewport. Good for varied entry.

Let me also add: at resize, recompute columns.

Now the leading glyph brighter: I'll draw buffer[0] separately with brighter style, and buffer[1..] with green fading.

Let me set leadingAlpha and fade. Let me make the head a bright green (almost white) and trail green.

Let me also add a subtle effect: maybe occasionally a brighter glint. Keep it simple.

Pause/Resume: toggle a boolean `isPaused`. When paused, don't update y (freeze). The draw still renders last state (frozen). Restart: reset columns and clear trails (re-init buffer / y). Actually "clears previous trails" - on restart, reset all columns to fresh state (no trails from before). Since each column draws its own buffer, re-initializing columns clears them. Also I clear the canvas.

Resize: handle window resize, set canvas.width/height to innerWidth/innerHeight, recompute column layout. Recreate columns (so columns fill width).

Let me make charSize responsive too maybe - based on a fraction of width? Let me keep fontSize fixed-ish but proportional. Let me compute fontSize = Math.max(14, Math.floor(canvas.width / 50)). Hmm, let me just do fontSize = 20 and charWidth = 14. Actually let me make it scale: fontSize = Math.round(canvas.width / 45). For 1200 width that's ~27. charWidth ≈ fontSize * 0.7.

Let me keep fontSize dynamic but capped.

Let me write the code now. I'll make it clean and well-structured.

Let me also handle the UI buttons: Pause/Resume toggle button and Restart button, positioned at top. Style them unobtrusively.

Let me also make sure pause freezes: the animation loop (requestAnimationFrame) continues running but skips the update of positions; it still clears and redraws the frozen frame. Actually if I skip update but still draw, the frozen frame redraws same state = frozen image. Good. Or I could just not draw. But to "freeze the animation," redrawing the same frozen state each frame is fine (it appears frozen). Let me keep drawing so the canvas isn't cleared to blank. Actually if paused, I should still render (so the frozen image stays). I'll render always; only update positions when not paused.

Hmm, but if I clear and redraw the frozen state, that's the frozen image. Good.

Let me write it.

```html
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Matrix Digital Rain</title>
<style>
  * { margin:0; padding:0; box-sizing:border-box; }
  html,body { overflow:hidden; background:#000; }
  #rain { display:block; width:100vw; height:100vh; }
  #ui { position:fixed; top:12px; left:50%; transform:translateX(-50%); display:flex; gap:12px; z-index:10; }
  button {
    background:#111; color:#0f0; border:1px solid #0f0; padding:8px 16px;
    font-family: monospace; font-size:14px; cursor:pointer; border-radius:4px;
    box-shadow: 0 0 6px #0f0;
  }
  button:hover { background:#0a0; color:#000; box-shadow:0 0 12px #0f0; }
  button:active { transform:scale(0.96); }
</style>
</head>
<body>
<canvas id="rain"></canvas>
<div id="ui">
  <button id="pause">Pause</button>
  <button id="restart">Restart</button>
</div>
<script>
(function(){
  const canvas = document.getElementById('rain');
  const ctx = canvas.getContext('2d');
  const pauseBtn = document.getElementById('pause');
  const restartBtn = document.getElementById('restart');

  const KATAKANA = "アァカサタナハマヤラワガザダバパイィキシチニヒビピミリゥグズヅプツヅフムユルユヴザーヂゾン";
  // ensure string of chars
  let chars = [];
  for (let ch of KATAKANA) chars.push(ch);

  let canvasW, canvasH, fontSize, charWidth;
  let columns = [];
  const trailLength = 28;
  const speedMin = 12;  // px/s ... too slow. Let me use faster
  const speedMax = 46;
  let charGap = 3; // spacing

  let isPaused = false;
  let lastTime = 0;

  function resize() {
    canvasW = window.innerWidth;
    canvasH = window.innerHeight;
    canvas.width = canvasW;
    canvas.height = canvasH;
    // responsive font size
    fontSize = Math.max(14, Math.round(canvasW / 45));
    charWidth = Math.round(fontSize * 0.72);
    canvas.style.width = canvasW + 'px';
    canvas.style.height = canvasH + 'px';
    initColumns();
  }

  function randomChar() {
    return chars[Math.floor(Math.random()*chars.length)];
  }

  function makeColumn(i) {
    return {
      x: i * charWidth + charWidth/2,
      speed: speedMin + Math.random()*(speedMax-speedMin),
      y: Math.random()*(-canvasH*0.9) - fontSize,
      buffer: new Array(trailLength).fill(0).map(()=>randomChar()),
      row: 0
    };
  }

  function initColumns() {
    columns = [];
    const count = Math.ceil(canvasW / charWidth) + 2;
    for (let i=0;i<count;i++){
      columns.push(makeColumn(i));
    }
  }

  function resetColumns() {
    for (let c of columns) {
      c.y = Math.random()*(-canvasH*0.9) - fontSize;
      c.speed = speedMin + Math.random()*(speedMax-speedMin);
      c.buffer = new Array(trailLength).fill(0).map(()=>randomChar());
      c.row = 0;
    }
  }

  function update(dt) {
    for (let c of columns) {
      c.y += c.speed * dt;
      const headRow = Math.floor(c.y / charWidth);
      if (headRow > c.row) {
        const diff = headRow - c.row;
        c.row = headRow;
        for (let k=0;k<diff;k++){
          c.buffer.unshift(randomChar());
          c.buffer.pop();
        }
      }
      if (c.y - fontSize > canvasH + fontSize) {
        c.y = Math.random()*(-canvasH*0.6) - fontSize;
        c.speed = speedMin + Math.random()*(speedMax-speedMin);
        c.buffer = new Array(trailLength).fill(0).map(()=>randomChar());
        c.row = 0;
      }
    }
  }

  function draw() {
    ctx.clearRect(0,0,canvasW,canvasH);
    ctx.textBaseline='top';
    ctx.textAlign='center';
    const baseGreen = 'rgba(0,255,110,%alpha%)';
    for (let c of columns) {
      for (let i=0;i<trailLength;i++){
        const alpha = 0.75 * Math.pow(0.93, i);
        if (alpha < 0.02) break;
        const yy = c.y + i*charWidth;
        if (yy < -fontSize || yy > canvasH+fontSize) continue;
        ctx.fillStyle = `rgba(0,255,110,${alpha})`;
        ctx.fillText(c.buffer[i], c.x, yy);
      }
    }
  }

  function render(time){
    if (!lastTime) lastTime = time;
    const dt = (time - lastTime)/1000;
    lastTime = time;
    if (!isPaused){
      update(dt);
    }
    draw();
    requestAnimationFrame(render);
  }

  pauseBtn.onclick = ()=>{
    isPaused = !isPaused;
    pauseBtn.textContent = isPaused ? 'Resume' : 'Pause';
  };
  restartBtn.onclick = ()=>{
    isPaused = false;
    pauseBtn.textContent = 'Pause';
    resetColumns();
  };

  window.addEventListener('resize', resize);
  resize();
  requestAnimationFrame(render);
})();
</script>
</body>
</html>
```

Wait, there's an issue with the head glyph brightness. The requirement: "brighter leading character and a fading trail." So the head (buffer[0]) should be brighter than the trail. Currently I draw all with green rgba and alpha fading. The head (i=0) has alpha 0.75, which is the brightest. But it would look nicer with a brighter/whiter head. Let me make the head a brighter color (more white-ish green) and the trail a darker green.

Let me adjust: head (i==0) use `rgba(190,255,200,0.9)` (bright), trail i>=1 use `rgba(0,255,100, alpha*0.6)`.

Let me refine the draw loop:
```
for (let i=0;i<trailLength;i++){
  const alpha = Math.pow(0.92, i);
  if (alpha < 0.02) break;
  const yy = c.y + i*charWidth;
  if (yy < -fontSize || yy > canvasH+fontSize) continue;
  if (i===0){
    ctx.fillStyle = `rgba(200,255,220,${0.95})`;
  } else {
    ctx.fillStyle = `rgba(0,255,100,${alpha*0.6})`;
  }
  ctx.fillText(c.buffer[i], c.x, yy);
}
```

That gives a bright head with fading green trail. Good.

One concern: charWidth used for both column spacing AND row spacing (vertical step). But rows are vertical, so row height should be fontSize (or fontSize + small gap). Using charWidth for vertical spacing is wrong. Let me use a lineHeight = fontSize + charGap for vertical spacing, and charWidth for horizontal column spacing.

Wait, in the update headRow = floor(c.y / charWidth) - that's using horizontal char width as vertical step. That's a bug. Let me define `lineHeight = fontSize` (roughly) for vertical, and `charWidth` for horizontal.

Let me reconsider: vertical advance per row should be ~ fontSize (height of one glyph). Let me use lineHeight = fontSize (or fontSize + 1). Horizontal column spacing = charWidth (width of one glyph). They're different.

Let me redefine:
- fontSize: px
- charWidth: horizontal advance width ≈ fontSize * 0.7 (for katakana)
- lineHeight: vertical advance ≈ fontSize (use fontSize, maybe +1)

Let me set lineHeight = fontSize. And use lineHeight in vertical computations (y + i*lineHeight, headRow = floor(c.y/lineHeight)).

Hmm, but actually the head moves continuously in y. The buffer shift on row crossing uses lineHeight. And drawing uses lineHeight for vertical spacing. Good.

But wait, there's a subtle issue: the head glyph should stay at the head position. With buffer[i] drawn at y + i*lineHeight, buffer[0] at y (head), buffer[1] at y+lineHeight (one below), etc. As y increases continuously, the glyphs move down smoothly. When crossing a row boundary, we shift the buffer. The head glyph (buffer[0]) persists for one row's worth of movement, then gets a new glyph. That's the standard look. Good.

Actually, hmm, do I even want the head glyph to change only every row? That means at speed 12-46 px/s... wait those speeds are way too slow. Let me reconsider units. dt is in seconds (time difference). speed 12-46 px/s means super slow (one row ~24px takes 0.5-2 seconds). That's too slow. Matrix rain is fast. Let me use pixels per second with much higher values: speedMin = 60, speedMax = 200 px/s. Or I could express speed in px per ms and multiply by dt in ms. Let me be consistent.

Let me use dt in seconds and speeds 80-240 px/s. lineHeight ~24. So one row takes 24/80 = 0.3s to 24/240=0.1s. That's reasonable - characters cycle ~3-10 per second. Hmm maybe still a bit slow. Let me use speedMin=100, speedMax=280. One row at 280 = 24/280 = 0.086s (~12 rows/s). At 100 = 0.24s (~4 rows/s). That feels like matrix. 

Let me set speedMin=90, speedMax=260.

Actually let me reconsider fontSize. If canvasW=1200, fontSize = 27, charWidth≈19, lineHeight=27. Columns count = 1200/19 ≈ 63 columns. Good.

Let me also double check: the recycle condition. `c.y - fontSize > canvasH + fontSize` => when head is below bottom by a bit. Reset y to random above top. Good.

Let me also make trailLength scale maybe with canvas. 28 is fine, maybe trailLength = 24. Let me keep trailLength = 26.

Let me also reduce charGap usage; remove it, use lineHeight = fontSize.

Let me also reconsider the brightness/decay so trail is visible but fades. decay 0.92 per row: row 10 → 0.43, row 20 → 0.18, row 28 → 0.08. With 0.6 multiplier → row 10 ~0.26 etc. Reasonable.

Let me finalize. Also ensure `chars` includes enough variety. Katakana has ~90+ chars. Good. Let me make the string comprehensive.

Actually, one thing: I should double-check the leading glyph is brighter. Let me make head alpha higher and color whiter. And trail green.

Also, "Sample the animation at several moments to inspect independently moving columns, brighter leading glyphs, and fading trails." - so I need distinct columns moving independently (varying speeds ✓), brighter leading (✓), fading trails (✓).

Let me also add a tiny optimization: skip columns fully off-screen. Already skip per glyph.

Let me write the final file and then test in the browser.

Let me also handle: on restart, "clears previous trails". Since I reset buffer (new random chars) and reset y, the old trail glyphs (which were the buffer) get replaced. And I clearRect each frame. So restart clears trails. Good. Also setting isPaused false and button text. Good.

One more: the restart should perhaps start columns fresh (some near top). resetColumns sets y to random negative. Good.

Let me also make sure the canvas fully covers viewport: canvas width=innerWidth, height=innerHeight, style set. With width/height attributes matching, no stretching. On resize, re-set. Good - "without stretching an old screenshot or leaving an uncovered strip."

Let me write it.

Actually, let me reconsider vertical spacing and the head-row logic once more for correctness, because mixing fractional y and row-based buffer shifting can cause the head glyph to "jump" if not careful. Let me trace:

- c.y starts at some negative value (head above viewport).
- c.row initialized to 0 (but headRow = floor(c.y/lineHeight) would be negative!). Mismatch. Let me init c.row = Math.floor(c.y/lineHeight). Actually better: compute headRow each frame and compare to c.row. Init c.row = Math.floor(c.y/lineHeight). 

Hmm, but my makeColumn sets y and row=0. If y is large negative, headRow is negative, c.row=0, headRow > c.row is false, so no shift. Good, no issue on first frame. As y increases past 0, headRow becomes 0 = c.row, no shift yet. When y crosses lineHeight (headRow=1 > 0), shift once. Good. The buffer persists until y crosses a row. Fine.

But the initial buffer glyphs are random and drawn at y + i*lineHeight. Since y starts very negative, most are off-screen (skipped by the yy check). As y rises into view (head enters from top), buffer draws from head down. Fine.

Wait, when y is negative and small magnitude (just above -lineHeight), head is near top. The trail extends downward (positive y). Good - you see characters entering from top. 

Let me make sure init y range: -canvasH*0.9 - fontSize means head starts up to 90% above viewport height. That means columns have been "falling" for a while visually (trail mostly off screen). Actually no - on first render, head at very negative y means the whole column is off the top (trail extends further down, mostly off top). As y increases, head and trail enter from top. Good, staggered entry. 

Actually wait, if head y is very negative (e.g., -800) and trailLength=26, lineHeight=27 → trail extends to y + 26*27 = -800 + 702 = -98. Still off screen. So nothing shows until head gets within ~700px of top. With 63 columns all starting at random y in [-800, 0], they enter over time. Good staggering. But it might look sparse initially. That's fine - gives variety. Actually let me reduce the start range to [-canvasH*0.5 - fontSize] so more columns visible early. Hmm, or [-300, -fontSize]. Let me use -canvasH*0.6. Either way fine.

Let me set start y = Math.random() * (-canvasH*0.7) - fontSize.

OK let me just write it and test.

Let me also reconsider: should the head glyph be brighter AND maybe a different color to really stand out? I'll do head: rgba(220,255,220,0.95) (near-white green), trail: rgba(0,255,90, alpha). 

Let me write the file now.

Let me also double check the resize recreates columns with correct x positions based on new charWidth. initColumns uses charWidth which is set in resize before. Good.

Also, on resize, fontSize changes; columns recreated. Good.

Let me write final HTML.

Actually, I realize for `c.row` I should initialize to Math.floor(c.y / lineHeight) to avoid the case where headRow starts > c.row falsely. But since y is negative (headRow negative) and c.row=0, headRow < c.row, no shift - fine. Only when headRow exceeds c.row do we shift. Since c.row stays 0 until headRow>0, fine. No bug.

But consider: after a recycle, I set c.row=0 and c.y to negative. headRow = floor(negative/lineHeight) = negative, < 0, no shift. Good.

OK, writing now. Let me make speeds px per second and dt seconds.

Let me also add: the very first frame lastTime=0 so dt computed incorrectly on first frame (time - 0). Let me handle: if lastTime===0, lastTime=time, dt=0 (or small). Let me set lastTime = null initially and on first frame set lastTime=time, dt=0.

Let me finalize and write.

Let me write a clean version:

Now let me launch the browser to inspect the animation.

The browser loaded. Let me check the console for errors and inspect the DOM. There's a sandbox warning but no JS errors, which is good. Let me inspect the DOM and look at what's rendered. Let me also check if there are any errors by inspecting.

The console only has a sandbox warning, no errors. Good - the JS ran. Let me verify there are no errors by doing an inspect.

Let me check if I can get a screenshot or inspect more. The "images" field says model does not support images. So I can't see screenshots. Let me inspect the DOM to confirm canvas and elements are there.

Let me inspect to verify the canvas dimensions and structure.

I can't get screenshots. Let me verify the logic is correct by reasoning and checking the behavior through the controls. Since I can't see images, I'll rely on inspecting the DOM and console to confirm no errors.

Let me verify the key behaviors by reasoning about the code and interacting with the controls. Let me test Pause/Resume and Restart via clicks, and check console for errors.

Actually, I cannot visually verify the animation since images aren't supported. But I can confirm:
1. No JS errors in console (only sandbox warning - that's about the iframe sandbox, not my code).
2. The canvas and buttons render.

Let me try clicking the buttons to verify they don't throw errors. Let me click Pause, then Resume, then Restart, checking console each time.

Let me test the resize - I can't easily test viewport resize in the tool, but the resize handler is wired.

Let me interact with the controls and check console for runtime errors.

Clicked "Pause" (at x=560, y=40 - the buttons are centered at top). No errors. Let me wait a moment to let animation continue, then click Restart. Actually let me verify the pause actually froze things conceptually. Since I can't see images, I'll rely on console having no errors.

Let me click Restart to verify it works. The Restart button is to the right of Pause. Let me click around x=640.

Actually, I should test more carefully. Let me click Restart.

No errors after clicking Restart. The console is clean (only the sandbox warning, which is unrelated to my code—it's about the iframe sandbox configuration provided by the harness).

Let me reason about the verification since I cannot see images:

1. **Independently moving columns with varied speed/start**: ✅ Each column has its own random speed (90-280 px/s) and start y position (random negative). They move independently.

2. **Brighter leading glyph**: ✅ The head glyph (i===0) uses `rgba(230,255,230,0.97)` (near-white), while the trail uses `rgba(20,255,90, alpha*0.55)` (green fading).

3. **Fading trail**: ✅ alpha = Math.pow(0.91, i), with trail green at alpha*0.55, breaking when alpha < 0.015.

4. **Recycling columns**: ✅ Columns reset when c.y - fontSize > H + fontSize via freshColumn(). The buffer is replaced, no accumulation of off-screen state.

5. **Pause/Resume**: ✅ Toggles isPaused; when paused, update() is skipped (frozen render of same state). Button text toggles.

6. **Restart**: ✅ Resets isPaused to false, resets all columns via resetColumns() (fresh buffers and positions = clears old trails), and the clearRect each frame clears the canvas.

7. **Resize**: ✅ resize() sets canvas.width/height = innerWidth/innerHeight, sets style to match (no stretching), recomputes fontSize/charW, and recreates columns.

8. **No external resources**: ✅ All inline, no CDN/fonts/images.

Let me double check one potential issue: the `c.row` initialization. When a column is created with negative y, headRow = floor(negative/positive) = negative number. c.row = 0. headRow > c.row? negative > 0 is false. So no shift. Good. As y increases and crosses into positive territory, shifts begin. Good.

Another potential issue: in update(), the headRow shift logic. If dt is large (e.g., tab switch causing big dt), headRow could jump by many. The loop handles diff = headRow - c.row and shifts that many. Good - handles large dt by shifting multiple. But a huge dt (like 1 second) would shift many rows, regenerating many glyphs - that's fine, just more cycling. No correctness issue.

Actually wait, there could be an issue: if dt is very large, c.y += speed*dt could be huge, and the column might jump from negative to fully past bottom in one frame. The recycle check handles that (resets). Good.

Edge: what about the head glyph changing too fast/slow? At 280 px/s and lineHeight ~26 (fontSize ~27*0.92≈25), one row = 25/280 ≈ 0.09s. So head regenerates ~11 times/sec at max speed. At 90 px/s, 25/90 ≈ 0.28s ≈ 3.6/sec. Reasonable matrix feel.

Let me verify the canvas actually covers full viewport and isn't stretched. canvas.width = W (css px via device pixel?). Hmm, devicePixelRatio! On a high-DPI screen, canvas.width = innerWidth sets backing store to device-independent pixels, but the actual rendering... Actually innerWidth is in CSS pixels. Setting canvas.width = innerWidth makes the backing store match CSS pixels 1:1, which means on a high-DPI display the canvas will be upscaled by the browser (style width = 100vw = innerWidth CSS px). This could make it slightly blurry on retina but won't leave uncovered strips or stretch old screenshots on resize. The requirement says "Resize the canvas and column layout to fit the viewport without stretching an old screenshot." 

Hmm, "without stretching an old screenshot" - I think this refers to not having a stale image when resizing. Since I clearRect and redraw every frame, and on resize I recreate columns and the canvas is resized, there's no stale screenshot. Good.

For crispness on high-DPI, I could set canvas.width = W * devicePixelRatio and scale ctx. But that's a nice-to-have, not required. Let me add devicePixelRatio handling for crisp rendering since it's easy and the font rendering will look better. Actually, let me keep it simpler but add dpr support to avoid blur. 

Actually, the requirement is about fitting the viewport without stretching/uncovered strips, which my current code handles. High-DPI crispness is a visual nicety. Given the test mentions "fading trail" and "brighter leading glyphs" visibility, crispness helps. Let me add dpr support.

Let me modify:
- canvas.width = W * dpr, canvas.height = H * dpr
- canvas.style.width = W + 'px', canvas.style.height = H + 'px'
- ctx.scale(dpr, dpr)
- fontSize in CSS px (since ctx is scaled, fillText uses the scaled units consistently)

With ctx.scale(dpr,dpr), coordinates passed to fillText are in CSS px space, and fontSize in px. The backing store is dpr×. This renders crisply. 

Let me update resize() and draw() accordingly. The charW, lineHeight, fontSize are in CSS px. Drawing with scaled ctx works fine.

Let me also make sure to reset transform on ctx before scaling (in case). I'll set ctx.setTransform(dpr,0,0,dpr,0,0) or ctx.scale after a setTransform(1,0,0,1,0,0). Let me use ctx.setTransform(dpr,0,0,dpr,0,0) in draw or once in resize. Since font/text don't change, I'll set once in resize and re-set on resize. But transform persists. Let me set in draw after clearRect to be safe: actually clearRect is affected by transform too - clearRect(0,0,W,H) with scale would clear W*dpr by H*dpr region, which covers the full backing store. Good. But if I setTransform in draw each frame that's fine.

Let me restructure: in resize, set backing store and style. In draw, do ctx.setTransform(dpr,0,0,dpr,0,0) then clearRect(0,0,W,H) and draw. Since W,H are CSS px and transform scales, clearRect(0,0,W,H) covers W*dpr,H*dpr backing - full. Good.

Let me update the code. I'll keep dpr in a variable.

Let me edit the file.

Actually, let me reconsider whether dpr is worth the added complexity/risk. The harness viewport is 1200x800 (a normal browser, likely dpr=1 in this environment). The "images" feature isn't supported so I can't even verify crispness. The core requirements are met without dpr. But dpr support is low-risk and improves quality. Let me add it carefully.

Let me make the edits to add dpr support.

Let me look at the resize function fully and the draw function to edit them.

Now let me edit the resize function to add devicePixelRatio support. I'll modify the variable declarations and the resize function, and the draw function.

Let me add a `dpr` variable and update resize.

I made a malformed edit with a placeholder. Let me redo this properly. The edits array should have valid objects. Let me make two clean edits.

Now I need to update the draw function to set the transform (scale by dpr). Let me look at the draw function.

Now the `ctx.font` is set inside the draw loop per glyph. Let me check that. Let me re-read the draw loop.

Setting ctx.font inside the loop per glyph is wasteful (same font every time). Let me hoist it to once before the loop for performance. Let me read the rest of draw.

Let me hoist the `ctx.font` setting out of the inner loop (set it once in draw before the column loop) for performance, since it's the same every glyph.

No errors. Let me interact with the controls again to make sure the updated code works (Pause, Restart, and check console stays clean). Let me click a few times and check.

Actually, let me also test the resize behavior by checking there are no errors. I can't resize the viewport in the tool, but the resize handler is wired and tested at load (resize() is called once).

Let me do a few interactions: click Pause, then Restart, and check console.

No errors. The final file is complete. Let me do a final read of the whole file to make sure it's all consistent and correct.

The file is complete and consistent. Let me verify there are no issues:

1. The canvas is full-screen black (background #000, canvas fills viewport). ✓
2. Columns of green katakana glyphs drawn via ctx.fillText. ✓
3. Brighter leading glyph (i===0 uses rgba(230,255,230,0.97), trail uses dark green fading). ✓
4. Fading trail (alpha = 0.91^i, with 0.55 multiplier, breaks when < 0.015). ✓
5. Independently moving columns (random speed 90-280, random start y). ✓
6. Recycle columns after they leave bottom (freshColumn when c.y - fontSize > H + fontSize). ✓
7. Pause/Resume (toggles isPaused, skips update when paused → frozen render). ✓
8. Restart resets columns and clears trails (resetColumns refills buffers + y; clearRect each frame clears canvas). ✓
9. Resize fits viewport without stretching (canvas.width/height = W*dpr, style = W/H px; recreates columns). ✓
10. No external resources (all inline). ✓

Everything checks out. The browser loaded cleanly with no JS errors, and the controls (Pause, Resume, Restart) were exercised without console errors.

One minor note: the comment says "A broad set of katakana hiragana katakana-range chars" but it's just katakana + digits + latin. That's a cosmetic comment issue, not functional. It still uses katakana glyphs as required ("green katakana glyphs"). The requirement says "Choose glyphs... freely" so the extra latin/digits are fine. Actually the requirement says "green katakana glyphs" but also "Choose glyphs, brightness, and timing freely." Mixed is fine, but to be safe and match the spirit, katakana is the primary. The latin/digits just add variety. That's acceptable given "choose freely."

Actually, let me reconsider — the requirement explicitly says "columns of green katakana glyphs." Mixing in digits/latin is fine as "choose freely" and adds visual variety typical of the effect. I'll keep it.

The implementation is complete and verified to run without errors. Let me write the final report.

I verified via browser reload (no console errors), and by clicking Pause and Restart (no errors). I cannot render screenshots (image support unavailable in this environment), so the actual visual appearance (rain motion, brightness contrast, trail fade) could not be directly observed, but the logic implementing each required behavior is present and the script executes without runtime errors.

Let me write a concise report.