Mandelbrot explorer · deepseek-v4-flash

The user wants me to build an interactive Mandelbrot-set explorer as a single-page web app in `index.html`. Let me plan this out:

1. Full-screen canvas
2. Mandelbrot set computation with smooth escape-time coloring
3. Drag to pan
4. Mouse-wheel zoom centered on cursor
5. Reset view button
6. Prevent page scroll from wheel
7. Recompute on navigation (no scaling)
8. Use sufficient iterations for detail
9. Responsive controls during rendering (async or chunked rendering)

Let me write a comprehensive implementation.

Key design decisions:
- Canvas 2D (simpler, works everywhere)
- Web Workers for computation to keep UI responsive... but no third-party libraries, so I could use a worker blob URL.
- Actually, I'll use a simple approach: render in chunks or use requestAnimationFrame with time-slicing, or use a Web Worker with inline code (Blob URL).

Let me use a Web Worker via a Blob URL to keep the UI responsive during rendering.

Complex plane bounds:
- Initial: center at (-0.5, 0), range about 3.5 x 2.5 (so from -2.25 to 1.25 in x, -1.25 to 1.25 in y)
- Actually, typical initial: x: [-2.5, 1.5], y: [-1.5, 1.5]

Smooth coloring:
- Use the standard formula: n + 1 - log(log(|z|))/log(2)
- Map to HSL or gradient

Let me write this out.

For the Web Worker approach:
- Create a blob URL for the worker script
- Worker receives imageData, bounds, maxIterations
- Worker computes pixel values and returns imageData
- Use transferable objects for performance

Let me implement this:

```javascript
// Worker code as a string
const workerCode = `
  self.onmessage = function(e) {
    const { width, height, xmin, xmax, ymin, ymax, maxIter } = e.data;
    const imageData = e.data.imageData;
    // or create new
    const data = new Uint8ClampedArray(width * height * 4);
    
    for (let y = 0; y < height; y++) {
      for (let x = 0; x < width; x++) {
        const cx = xmin + (x / width) * (xmax - xmin);
        const cy = ymin + (y / height) * (ymax - ymin);
        
        let zx = 0, zy = 0;
        let n = 0;
        let zx2 = 0, zy2 = 0;
        
        while (zx2 + zy2 <= 4 && n < maxIter) {
          zy = 2 * zx * zy + cy;
          zx = zx2 - zy2 + cx;
          zx2 = zx * zx;
          zy2 = zy * zy;
          n++;
        }
        
        const idx = (y * width + x) * 4;
        if (n === maxIter) {
          // Inside set - black
          data[idx] = 0;
          data[idx+1] = 0;
          data[idx+2] = 0;
          data[idx+3] = 255;
        } else {
          // Smooth coloring
          const log_zn = Math.log(zx2 + zy2) / 2;
          const nu = Math.log(log_zn / Math.log(2)) / Math.log(2);
          const iter = n + 1 - nu;
          const hue = 0.95 + iter / maxIter;
          // Convert HSL to RGB...
        }
      }
    }
    
    self.postMessage({ imageData: data, width, height }, [data.buffer]);
  };
`;
```

Actually, let me think about HSL to RGB conversion. I'll use a smooth gradient.

Let me write the full file now. I'll be careful to handle all the requirements.

Let me also think about the smooth coloring formula more carefully.

The standard smooth coloring:
- After escape, compute: `smooth = n + 1 - Math.log(Math.log(Math.sqrt(zx2 + zy2))) / Math.log(2)`
- Or equivalently: `smooth = n - Math.log(Math.log(zx2 + zy2) / 2) / Math.log(2)`

For coloring, I'll use: `hue = (smooth / maxIter) * 360` or some variation.

Actually a common approach: use a fixed color palette based on the smooth iteration count, modulo some range.

Let me use a nice color scheme. I'll map the smooth value to HSL colors.

For inside the set: I'll use a dark color (like very dark blue/black with maybe a slight gradient for a nebula effect).

Let me write the complete implementation now.

I need to be careful about:
1. Drag to pan - track mouse down, move, up
2. Wheel zoom centered on cursor position
3. Reset button
4. Prevent default on wheel to stop page scrolling
5. Re-render on each navigation
6. Chunked or worker-based rendering for responsiveness

Let me write this all out now.

For the worker, I'll create a Blob URL from the worker code string.

For responsive controls during rendering: the worker handles computation in the background, so the UI thread stays responsive. I can also add a loading indicator.

Let me structure this:

```html
<!DOCTYPE html>
<html>
<head>
<style>
  /* Full screen canvas, no scroll */
</style>
</head>
<body>
<canvas id="canvas"></canvas>
<div id="controls">
  <button id="resetBtn">Reset view</button>
  <span id="info">...</span>
</div>
<script>
// All JavaScript
</script>
</body>
</html>
```

Let me now write the complete code.

For the HSL to RGB conversion function, I'll include that.

For the color mapping, I'll use something like:
- Inside set: RGB(0, 0, 30) (very dark blue)
- Outside: smooth color based on iteration count

Let me also think about the iteration count adaptively. As we zoom in, we need more iterations. I'll dynamically adjust: `maxIter = Math.max(50, Math.round(50 + 50 * Math.log(1 + zoomLevel)))` or something like that.

Actually, let me base it on the size of the viewport in the complex plane:
- The smaller the view, the more iterations needed
- `maxIter = Math.max(50, Math.round(100 + 200 * Math.log(xmax - xmin, 2)))`
- Or: `maxIter = Math.max(50, Math.round(100 - 100 * Math.log10(xmax - xmin)))`

Let me use: `maxIter = Math.max(50, Math.round(80 + 40 * Math.log2(4 / (xmax - xmin))))`

That way at zoom level where range is 4 (initial), we get ~80 iterations. At range 0.04, we get ~80 + 40*7 = 360 iterations. At range 0.0004, we get ~80 + 40*13 = 600 iterations. That should be reasonable.

Actually let me tune this: for initial view (range ~3.5), we need maybe 50-100 iterations. For deep zooms, we need hundreds or thousands. Let me use:

```javascript
const range = xmax - xmin;
const maxIter = Math.max(50, Math.min(1000, Math.round(100 + 50 * Math.log2(3.5 / range))));
```

This gives:
- range 3.5: 100 iterations
- range 0.35: 100 + 50*3.32 = 266 iterations
- range 0.035: 100 + 50*6.64 = 432 iterations
- range 0.0035: 100 + 50*10 = 600 iterations
- range 0.00035: 100 + 50*13.3 = 765 iterations (capped at 1000)

That should work well.

Let me also implement the drag panning properly:
- On mousedown, record the starting point and the current bounds
- On mousemove, compute the delta and update bounds
- On mouseup, stop dragging and re-render

Wait, should we re-render during drag or after? For performance, I'll re-render after the drag ends (on mouseup). During the drag, I could show a preview or just the old image moving... but since we're not scaling, it makes more sense to render after the drag completes.

Actually, for better UX, let me render on drag end (mouseup). During drag, I might just redraw the old image translated (stretched) - but that's not "recomputing" so it's misleading. Let me skip that and just re-render on drag end.

Hmm, but the user can hold the mouse button and drag - they won't see movement. Let me at least show something. I could show a "please wait" indicator. Let me just re-render on mouseup and show a loading state during rendering.

Actually, I think re-rendering during drag (as the user moves the mouse) could work if I throttle it with requestAnimationFrame and the worker is fast enough. But if rendering takes time, each drag position would queue a new render. Let me use a simple approach: render on mouseup.

But let me improve: render on mouseup AND also immediately show a transformed version of the old canvas during drag. So during drag, I save the previous render and translate it. On mouseup, I do a full recompute.

Wait, the requirement says: "Dragging pans the image with the pointer" - this means the user should see the image move as they drag. So I need to either:
1. Re-render continuously during drag (slow)
2. Save the previous render and show it translated during drag, then re-render on release

Option 2 is better. Let me do that.

So during drag:
- Draw the previously rendered image offset by the drag delta
- On mouseup: trigger a full recompute

This is a good approach.

Let me now write the complete code.

For the drag visual feedback during drag, I'll use the canvas's drawImage to redraw the previous frame at the offset position. I need to keep a copy of the previous render.

Actually, simpler: I can use the fact that canvas is just a bitmap. When dragging starts, I save the current canvas content via `getImageData` or `toDataURL`. Then during drag, I clear and draw that image at the offset.

Wait, but the canvas might not be dirty yet on first render... Let me think about this.

Here's my plan:

1. Initial render: compute with worker, put image data on canvas, save snapshot
2. On mousedown: record start position, save canvas snapshot
3. On mousemove (while dragging): calculate offset, clear canvas, draw snapshot at offset
4. On mouseup: compute new bounds from drag, re-render with worker, save new snapshot

For zoom:
1. On wheel: compute new bounds centered on cursor position, re-render with worker

Let me code this up now. I'll use a worker for rendering.

Let me also handle window resize.

Let me also add escape to prevent wheel scrolling.

I think I have enough planned. Let me write the file.

One more thing - the color scheme. Let me use a nice-looking palette:

Inside set: very dark blue/black, maybe `rgb(0, 0, 20)`

Outside set: smooth coloring using HSL. I'll convert the smooth iteration to a hue that cycles through the color spectrum.

A common approach that looks nice:

```javascript
function smoothColor(iter, maxIter, zx2, zy2) {
  if (iter >= maxIter) {
    return [0, 0, 20]; // inside
  }
  const log_zn = Math.log(zx2 + zy2) / 2;
  const nu = Math.log(log_zn / Math.log(2)) / Math.log(2);
  const smooth = iter + 1 - nu;
  
  // Map to HSL
  const hue = (360 * smooth / maxIter) % 360;
  const saturation = 80;
  const lightness = 50 + 30 * Math.sin(smooth * 0.1);
  
  // Convert HSL to RGB
  return hslToRgb(hue / 360, saturation / 100, lightness / 100);
}
```

Actually, let me use a more standard and visually appealing scheme. A common one is to use a color palette based on the iteration count with some variation:

```javascript
function getColor(n, maxIter, zx2, zy2) {
  if (n >= maxIter) return [0, 0, 0];
  
  // Smooth iteration count
  const log_zn = Math.log(zx2 + zy2) / 2;
  const nu = Math.log(log_zn / Math.log(2)) / Math.log(2);
  const smooth = n + 1 - nu;
  
  // Use smooth value to determine color
  const t = smooth / maxIter;
  
  // Create a nice gradient
  const r = Math.sin(2 * Math.PI * t * 2 + 0) * 0.5 + 0.5;
  const g = Math.sin(2 * Math.PI * t * 2 + 2.094) * 0.5 + 0.5;
  const b = Math.sin(2 * Math.PI * t * 2 + 4.188) * 0.5 + 0.5;
  
  return [r * 255, g * 255, b * 255];
}
```

Hmm, that's a bit simple. Let me use a more refined approach.

Actually, a very popular coloring for the Mandelbrot set uses the concept of "normalized iteration count" and then maps it through a color gradient. Let me create a nice gradient:

```javascript
function computeColor(n, maxIter, zx2, zy2) {
  if (n >= maxIter) return [0, 0, 0]; // black for inside
  
  // Smooth iteration count
  const log_zn = Math.log(zx2 + zy2) / 2;
  const nu = Math.log(log_zn / Math.log(2)) / Math.log(2);
  const smooth = n + 1 - nu;
  
  // Normalized value 0-1
  const t = smooth / maxIter;
  
  // Create a color gradient using sine waves with different phases
  const r = Math.pow(Math.sin(2 * Math.PI * (t * 3 + 0.0)), 1);
  const g = Math.pow(Math.sin(2 * Math.PI * (t * 3 + 0.333)), 1);
  const b = Math.pow(Math.sin(2 * Math.PI * (t * 3 + 0.667)), 1);
  
  return [
    Math.round(r * 255),
    Math.round(g * 255),
    Math.round(b * 255),
    255
  ];
}
```

This creates a repeating pattern with 3 cycles across the range.

Let me refine to make it look more like a classic Mandelbrot render. I'll use a color scheme that goes from dark to light with interesting hues:

```javascript
// Inside set - use a gradient from dark blue to black
// Actually, inside the set, use a very dark color
```

OK let me just write the code now. I'll iterate on colors if needed.

Let me also consider that the user might want to see the inside of the set with some subtle coloring (like a dark gradient) rather than pure black.

Here's my final plan for the file:

```html
<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>Mandelbrot Explorer</title>
  <style>
    /* Reset, full screen canvas, overlay controls */
  </style>
</head>
<body>
  <div id="container">
    <canvas id="canvas"></canvas>
    <div id="controls">
      <button id="resetBtn">Reset view</button>
      <span id="status"></span>
    </div>
    <div id="coords"></div>
  </div>
  <script>
    // All JS
  </script>
</body>
</html>
```

Let me code this up now. I'll create a complete, high-quality implementation.

Let me think about how to structure the worker code. I'll inline it as a string and create a Blob URL.

```javascript
const workerScript = `
  self.onmessage = function(e) {
    const { width, height, xmin, xmax, ymin, ymax, maxIter } = e.data;
    const pixels = new Uint8ClampedArray(width * height * 4);
    
    function hslToRgb(h, s, l) {
      // ... standard conversion
    }
    
    for (let py = 0; py < height; py++) {
      for (let px = 0; px < width; px++) {
        const cx = xmin + (px / width) * (xmax - xmin);
        const cy = ymin + (py / height) * (ymax - ymin);
        
        let zx = 0, zy = 0;
        let zx2 = 0, zy2 = 0;
        let n = 0;
        
        while (zx2 + zy2 <= 4 && n < maxIter) {
          zy = 2 * zx * zy + cy;
          zx = zx2 - zy2 + cx;
          zx2 = zx * zx;
          zy2 = zy * zy;
          n++;
        }
        
        const idx = (py * width + px) * 4;
        if (n >= maxIter) {
          // Inside - dark with subtle nebula coloring
          pixels[idx] = 0;
          pixels[idx+1] = 0;
          pixels[idx+2] = 15;
          pixels[idx+3] = 255;
        } else {
          // Smooth coloring
          const log_zn = Math.log(zx2 + zy2) / 2;
          const nu = Math.log(log_zn / Math.log(2)) / Math.log(2);
          const smooth = n + 1 - nu;
          
          const t = smooth / maxIter;
          // Color gradient
          const h = (0.95 + t * 2) % 1.0;
          const s = 0.6 + 0.4 * Math.sin(t * 10);
          const l = 0.5 + 0.4 * Math.sin(t * 7 + 1);
          
          const [r, g, b] = hslToRgb(h, s, l);
          pixels[idx] = r;
          pixels[idx+1] = g;
          pixels[idx+2] = b;
          pixels[idx+3] = 255;
        }
      }
    }
    
    self.postMessage({ pixels: pixels.buffer, width, height }, [pixels.buffer]);
  };
`;
```

Wait, I can't post just the buffer, I need to post it as a property and mark it for transfer. Actually, in the worker, `postMessage` with transferable:

```javascript
self.postMessage({ pixels: pixels.buffer, width, height }, [pixels.buffer]);
```

And on the main thread:
```javascript
worker.onmessage = function(e) {
  const { pixels, width, height } = e.data;
  const imageData = new ImageData(new Uint8ClampedArray(pixels), width, height);
  ctx.putImageData(imageData, 0, 0);
};
```

Wait, `pixels` in the message is an ArrayBuffer, so I need to wrap it in Uint8ClampedArray.

Actually, let me rethink. When you post a transferable, it becomes detached in the sender and available in the receiver. The `e.data.pixels` will be an ArrayBuffer. So I do:

```javascript
const imageData = new ImageData(new Uint8ClampedArray(e.data.pixels), e.data.width, e.data.height);
```

OK let me write the full implementation now.

Let me also think about the HSL to RGB function. Standard algorithm:

```javascript
function hslToRgb(h, s, l) {
  let r, g, b;
  if (s === 0) {
    r = g = b = l;
  } else {
    const hue2rgb = (p, q, t) => {
      if (t < 0) t += 1;
      if (t > 1) t -= 1;
      if (t < 1/6) return p + (q - p) * 6 * t;
      if (t < 1/2) return q;
      if (t < 2/3) return p + (q - p) * (2/3 - t) * 6;
      return p;
    };
    const q = l < 0.5 ? l * (1 + s) : l + s - l * s;
    const p = 2 * l - q;
    r = hue2rgb(p, q, h + 1/3);
    g = hue2rgb(p, q, h);
    b = hue2rgb(p, q, h - 1/3);
  }
  return [Math.round(r * 255), Math.round(g * 255), Math.round(b * 255)];
}
```

OK I think I have everything I need. Let me write the complete file now.

Let me also consider: the worker script needs to include the hslToRgb function. I'll include it in the worker script string.

One issue: when I put hslToRgb inside the worker script string, I need to be careful about string escaping. Let me use a template literal or just put the function in the worker code as a string.

Actually, I'll build the worker code as a function toString() approach or just a multi-line string.

Let me use the approach of creating a Blob from a string:

```javascript
const workerBlob = new Blob([workerCode], { type: 'application/javascript' });
const workerUrl = URL.createObjectURL(workerBlob);
const worker = new Worker(workerUrl);
```

This works well.

Let me now write the complete file. I'll be thorough and make it look good.

Here's my complete implementation plan:

1. HTML structure with full-screen canvas and overlay controls
2. CSS for full-screen layout, overlay controls styling
3. JavaScript:
   a. Canvas setup with resize handling
   b. Complex plane bounds management
   c. Worker creation for computation
   d. Rendering pipeline
   e. Drag-to-pan with visual feedback
   f. Wheel zoom centered on cursor
   g. Reset view
   h. Status display
   i. Coordinate display
   j. Prevent default wheel

Let me write it all now.

Let me think about one more thing: during drag, I'll save the canvas content after each render, and during drag movement, I'll draw that saved content at the offset position. To save canvas content, I can use `ctx.getImageData()` or better, create an offscreen canvas and copy to it.

Actually, the simplest approach: after each render completes, save a copy of the rendered pixels. During drag, use `drawImage` to draw the saved copy at the offset position.

I'll use an offscreen canvas for this.

Let me finalize and write the code.

Actually for the drag, let me use a simpler approach: I'll keep the rendered image on the canvas, and during drag, I can just translate the canvas context so the existing image appears to move. Then on drag end, I compute new bounds and re-render.

Wait, that won't work well because the canvas content is already at the right position. Let me think...

Actually, here's a clean approach:

1. After each render, save the ImageData (or use getImageData to capture the canvas)
2. During drag:
   - Clear canvas
   - Draw the saved image at an offset (dx, dy) calculated from the drag delta
3. On drag end: compute new bounds and re-render

For saving, I'll use an off-screen canvas that I keep hidden.

Let me implement this.

```javascript
// After render:
offscreenCanvas.width = canvas.width;
offscreenCanvas.height = canvas.height;
offscreenCtx.drawImage(canvas, 0, 0);

// During drag:
ctx.clearRect(0, 0, canvas.width, canvas.height);
ctx.drawImage(offscreenCanvas, dx, dy);
```

This should work well. The offscreen canvas just stores the last rendered frame.

OK, let me write the full code now. I'll be careful about all the details.

For the color scheme, I want something visually appealing. Let me use a scheme that creates a nice gradient from dark to light with color variation. Here's a refined approach:

```javascript
// Inside set: dark with slight blue/purple hue
// Using a smooth gradient based on the number of iterations before bailout
// For inside points, we could use the final angle to create a "distance estimator" coloring
// But for simplicity, just use a solid dark color with subtle variation

if (n >= maxIter) {
  // Try to get some interior detail using the final z value's argument
  // const angle = Math.atan2(zy, zx);
  // This gives some structure to the interior
  // For simplicity, just use dark blue/black
  pixels[idx] = 0;
  pixels[idx+1] = 0;
  pixels[idx+2] = 15 + Math.floor(Math.sin(angle * 3) * 5);
  pixels[idx+3] = 255;
}
```

Actually, for inside coloring, using the argument of the final z value gives a nice "orbit trap" effect. Let me include that.

OK let me just write the code. I've spent enough time planning.

Let me also think about performance. The worker handles computation in parallel. But for very deep zooms with many iterations, it might be slow. I should show a loading state.

For the initial render, I should also optimize by checking if points are in the main cardioid or period-2 bulb to skip computation for those (they're guaranteed to be in the set). But this adds complexity. Let me skip this optimization and just rely on the worker.

Let me now write the file.

One more thing: I need to handle the case where the user zooms while a render is in progress. I should cancel the current render and start a new one. I can do this by terminating the worker and creating a new one, or by keeping track of the render ID and ignoring old results.

The simplest approach: maintain a render counter. When a render completes, check if the counter matches. If not, ignore the result. Also, before starting a new render, discard the old worker (terminate it) and create a new one.

Actually, terminating and recreating a worker is clean but has overhead. Let me use the render ID approach: each render request has an ID, and we only apply results from the latest ID.

Let me use this approach:

```javascript
let renderId = 0;
let currentWorker = null;

function render() {
  renderId++;
  const id = renderId;
  
  if (currentWorker) {
    currentWorker.terminate();
  }
  
  const worker = createWorker();
  currentWorker = worker;
  
  worker.onmessage = function(e) {
    if (id !== renderId) return; // stale
    // Apply pixels to canvas
    // ...
    currentWorker = null;
  };
  
  worker.postMessage({...});
}
```

Actually, terminating a worker while it's computing is fine - it frees up resources. And creating a new worker for each render is simple. Let me do that.

Let me write the complete code now. I'll aim for a clean, well-structured implementation.

Let me also think about the initial view bounds:
- Center: (-0.5, 0)
- Range: 3.5 (so x from -2.25 to 1.25, y from -1.25 to 1.25... wait, that would make y range 2.5, which is fine but we need to account for aspect ratio.

The aspect ratio of the canvas will determine the actual bounds. If canvas is wider than tall, the x range should be larger than y range, or vice versa.

I'll compute bounds based on the aspect ratio:
- Set a reference range (e.g., 3.5 in x direction)
- Compute y range based on aspect ratio

```javascript
const aspectRatio = canvas.width / canvas.height;
const refRange = 3.5; // x range
const xRange = refRange;
const yRange = refRange / aspectRatio;
const centerX = -0.5;
const centerY = 0;
const xmin = centerX - xRange / 2;
const xmax = centerX + xRange / 2;
const ymin = centerY - yRange / 2;
const ymax = centerY + yRange / 2;
```

This ensures the initial view shows the entire cardioid and main lobes.

OK let me write the complete file now. Here we go.

Let me also plan the controls layout:
- A small overlay in the bottom-left or top-right corner
- Reset button
- Status text (rendering... or zoom level)
- Maybe coordinate display

Let me put controls in the bottom-left, styled nicely with some transparency.

Alright, writing the file now.

Actually wait, I want to handle a subtle issue. When the user drags and we show the previous frame offset, the offset is in screen pixels. But the complex plane bounds need to be computed from the screen offset. When the user releases the drag:

```javascript
const dx = startX - currentX; // in screen pixels
const dy = startY - currentY;
const xRange = xmax - xmin;
const yRange = ymax - ymin;
const newXmin = xmin + (dx / canvas.width) * xRange;
const newXmax = xmax + (dx / canvas.width) * xRange;
const newYmin = ymin + (dy / canvas.height) * yRange;
const newYmax = ymax + (dy / canvas.height) * yRange;
```

Wait, if the user drags to the right (mouse moves right), the image should move right, meaning the complex plane should shift left. Let me think about this carefully.

When you drag the image to the right, you're moving the viewport to see more of the right side. So the center of the view moves to the right. If the mouse moves from (100, 200) to (150, 200) (right by 50px), the center should move right by (50/width) * xRange.

Hmm, actually when you drag an image, it feels like you're moving the canvas under the mouse. So if you drag right, you want to see what was to the right. So the bounds shift right: xmin and xmax both increase.

But the pixel offset during drag works the opposite: if you drag right by 50px, you draw the saved image 50px to the right (dx=50), which means the image moves right relative to the viewport.

Wait, let me think about this more carefully.

In most image viewers, if you click and drag to the right:
- The image moves to the right
- You see more of the left side of the image

But for a fractal explorer, when you drag right:
- You want to explore the region to the right of your current view
- So the complex bounds should shift to the right (xmin and xmax increase)

But the visual feedback during drag: if you're dragging right, the previous render should appear to translate right, showing empty space on the left.

So: drag direction = direction the image moves. If mouseX increases (right drag), dx = mouseX - startX (positive), the image draws at (dx, 0). This means the image is shifted right, showing more of the left side. But we actually want to see the right side.

Hmm, no. Let me think again.

In Google Maps, when you drag right:
- The map moves right
- You see more of the left side (the map reveals what was offscreen to the left)

But for a Mandelbrot explorer, we want the opposite: dragging right should reveal more of the set on the right side. So it's like we're looking through a window and moving the window to the right.

If the window moves right, the content seen through the window shifts left relative to the window. So the saved image should appear to shift left.

OK let me just use the convention: drag right → shift bounds right (to see more of the right). During drag, the saved image shifts in the OPPOSITE direction of the drag (so it appears the view is moving with the drag, showing more content on the drag side).

Actually the most natural feel: when you drag right, the viewport moves right relative to the fractal. So the fractal appears to move left relative to the viewport. In terms of the image offset on screen: dx = -(mouseX - startX), so the image moves opposite to the drag direction.

Let me verify: user drags right (mouse moves from x=100 to x=150).
- dx = -(150 - 100) = -50
- Image is drawn at (-50, 0), i.e., shifted left by 50px
- This means the right side of the image is no longer visible, and empty space appears on the right
- This visually feels like "moving to the right" to see more of the right side

Yes, that's correct. So during drag:
```javascript
const dx = -(mouseX - dragStartX);
const dy = -(mouseY - dragStartY);
```

And on release, the new bounds:
```javascript
const dx = dragStartX - mouseX; // = (mouseX - dragStartX) * -1
const newXmin = xmin + (dx / canvas.width) * (xmax - xmin);
```

Wait, let me recalculate. If the image is shifted left by 50px (dx=-50), that means:
- The left edge of the visible area now shows stuff that was 50px to the left of the original left edge
- In complex coordinates, that's xmin - 50/width * (xmax - xmin)
- The right edge now shows stuff that was... hmm, this is getting confusing.

Let me think about it differently. After the drag, the new view should be the old view shifted by the drag vector in complex space. If the user dragged right by 50px (on screen), the new view should be the old view shifted right by 50px worth of complex coordinates.

In terms of screen coordinates, the viewport has moved right. The image, as drawn, should shift left relative to the viewport (so that the right side of the old image moves to the center, revealing the new right side).

So the offset for the saved image during drag: `dx = -(mouseX - startX)`, `dy = -(mouseY - startY)`.

And the new bounds after drag:
```
dx_complex = -(mouseX - startX) / canvas.width * (xmax - xmin)
```
Wait no. Let me just think about it practically.

The user starts dragging at (startX, startY) and the mouse moves to (currentX, currentY).

The drag delta is (currentX - startX, currentY - startY).

The viewport should shift by this delta. So the new center should be:
```
newCenterX = oldCenterX + (currentX - startX) / canvas.width * (xmax - xmin)
newCenterY = oldCenterY + (currentY - startY) / canvas.height * (ymax - ymin)
```

The image offset during drag (for visual feedback):
The old image should appear to have moved by -(currentX - startX) pixels in x and -(currentY - startY) pixels in y. Because we're looking through the viewport and moving the viewport right means the image seen through it shifts left.

Hmm wait. Actually if the viewport moves right by delta, the content at position x in the old viewport is now at position x - delta in the new viewport. So the image should be drawn with a leftward shift (negative delta).

But actually the visual feedback during drag is commonly implemented as: the image moves WITH the cursor. So if you drag right, the image moves right too, revealing new content on the left. This is what feels natural to most users.

Wait, let me check: on Google Maps, when you drag right, the map moves right (so you see new content on the right). No wait, moving right means... 

Actually on Google Maps, if you grab and drag to the right, the map shifts to the right, meaning you see more content on the LEFT side. Because the map moving right reveals what was previously off-screen on the left.

But for a fractal explorer, I think the more natural behavior is: if you drag right, you want to look to the right of the current view, so the viewport moves right. The fractal image should appear to move left during the drag (revealing the right side).

Actually, I've seen both conventions. Let me just go with: the image follows the cursor during drag. So if you drag right, the image moves right. This reveals content on the left (shows what was offscreen to the left). On release, the bounds are recomputed so that the content matches.

Actually, you know what, let me just go with the simplest convention that most users expect: when you drag in a direction, the view moves in that direction. So if you drag right, the new view is centered further right. During drag, the previous image shifts left to create the visual of moving right.

Let me just implement it this way:

During drag:
```
dx = currentX - startX;  // positive = drag right
// Draw saved image at (-dx, -dy) on canvas
// This means when dragging right (dx positive), image shifts left
```

On release:
```
// The viewport moved by dx pixels to the right
// So the bounds shift right by dx pixels worth of complex coordinates
newXmin = xmin + (dx / canvas.width) * xRange;
newXmax = xmax + (dx / canvas.width) * xRange;
```

Hmm wait, this means the image visible at the end of drag (before recompute) would show content shifted left from the original. But the new bounds are shifted right. That doesn't match!

Let me reconsider. When the user drags right:
- The saved image is drawn at (-dx, 0) where dx is positive
- This means the image appears shifted to the LEFT
- Empty space appears on the RIGHT side of the canvas
- This visually shows us that we're looking at a new area to the RIGHT

After the drag, the new bounds should be shifted RIGHT (so xmin and xmax increase). This way, when we recompute, the new image shows the area to the right, which was the empty space during the drag.

So: during drag, image offset is (-dx, -dy). After drag, bounds shift by (dx * range/width, dy * range/height).

But wait, the image during drag at offset (-dx, 0) shows content from the OLD render at positions x + dx in the original. The new bounds have shifted right by dx in screen space. So the new render at those bounds should show... Let me check.

If old xmin = -2.25, old xmax = 1.25, canvas width = 1000.
User drags right by 100px.
During drag: image drawn at offset (-100, 0). So pixel at x=200 in the canvas now shows the pixel that was at x=300 in the original render. In complex coordinates, x=300 is: -2.25 + 300/1000 * 3.5 = -2.25 + 1.05 = -1.20.

After drag, new bounds should be shifted right by 100/1000 * 3.5 = 0.35:
newXmin = -2.25 + 0.35 = -1.90
newXmax = 1.25 + 0.35 = 1.60

Now, the pixel at x=200 in the new render would be at: -1.90 + 200/1000 * 3.5 = -1.90 + 0.70 = -1.20. This matches! Good.

So the math checks out. During drag, image offset = (-dx, -dy). After drag, bounds shift by (dx * xRange/width, dy * yRange/height).

Let me implement it this way.

OK, I'm confident in the approach now. Let me write the complete file.

Let me also add keyboard shortcut 'r' for reset as a nice touch.

Here's the structure of my JavaScript:

```javascript
// State
let xmin, xmax, ymin, ymax;
let canvas, ctx;
let offscreenCanvas, offscreenCtx;
let worker;
let renderId = 0;
let isRendering = false;
let isDragging = false;
let dragStartX, dragStartY;
let savedImageData = null;

// Functions
function init() { ... }
function resize() { ... }
function computeBounds() { ... }
function render() { ... }
function createWorker() { ... }
function handleDragStart(e) { ... }
function handleDragMove(e) { ... }
function handleDragEnd(e) { ... }
function handleWheel(e) { ... }
function resetView() { ... }
```

Alright, let me write the actual file now. I'll combine everything into one clean implementation.

Let me think about what color scheme to use. I want something that looks great. Let me use a scheme inspired by popular visualizations:

For outside points (escaped):
- Map smooth iteration count to a color
- Use a repeating gradient with nice colors

For inside points (not escaped):
- Very dark color, maybe with some slight variation based on the orbit

Here's a nice color scheme I'll use:

```javascript
// Outside
const t = smooth / maxIter;
const r = Math.round(255 * Math.pow(Math.sin(2 * Math.PI * (t * 2.5 + 0.0)), 2));
const g = Math.round(255 * Math.pow(Math.sin(2 * Math.PI * (t * 2.5 + 0.333)), 2));
const b = Math.round(255 * Math.pow(Math.sin(2 * Math.PI * (t * 2.5 + 0.666)), 2));
```

Using power of 2 (squared) gives sharper color transitions.

Actually, let me use a more refined scheme. Let me compute the color based on the smooth value:

```javascript
function smoothColor(smooth, maxIter) {
  const t = smooth / maxIter;
  // Create a nice palette
  const c = [
    Math.sin(2 * Math.PI * (t * 3 + 0.00)) * 0.5 + 0.5,
    Math.sin(2 * Math.PI * (t * 3 + 0.33)) * 0.5 + 0.5,
    Math.sin(2 * Math.PI * (t * 3 + 0.67)) * 0.5 + 0.5,
  ];
  // Apply gamma correction
  return c.map(v => Math.round(255 * v * v));
}
```

Actually, let me use a more interesting color mapping. I'll use the classic approach where the color is based on the hue derived from the smooth iteration count:

```javascript
const hue = 360 * (smooth / maxIter * 2 + 0.5) % 360;
const sat = 80 + 20 * Math.sin(smooth * 0.5);
const lig = 40 + 30 * Math.sin(smooth * 0.7 + 1);
// Convert HSL to RGB
```

Let me use something that creates a nice gradient. I'll go with the sine-based RGB approach but with carefully chosen parameters.

OK let me just write the code. I'll make the colors look good.

Here's my final approach for coloring:

For outside points:
```javascript
const t = smooth / maxIter;
// Mix multiple frequency waves
const r = Math.max(0, Math.min(255, Math.round(
  200 * (0.5 + 0.5 * Math.sin(2 * Math.PI * (t * 2.0 + 0.0)))
)));
const g = Math.max(0, Math.min(255, Math.round(
  200 * (0.5 + 0.5 * Math.sin(2 * Math.PI * (t * 2.0 + 0.33)))
)));
const b = Math.max(0, Math.min(255, Math.round(
  200 * (0.5 + 0.5 * Math.sin(2 * Math.PI * (t * 2.0 + 0.67)))
)));
```

This creates a repeating color pattern with 2 cycles, using sine waves. Values range from 0 to 200, giving a nice vibrant look.

For inside points, I'll use very dark blue:
```javascript
r = 0, g = 0, b = 10
```

But I could also add some subtle interior detail. Let me include the argument of the final z value:

```javascript
// For interior coloring, use the last computed z value
const angle = Math.atan2(zy, zx);
r = 0;
g = Math.floor(5 + 5 * Math.sin(angle * 2));
b = Math.floor(10 + 10 * Math.cos(angle * 3));
```

This gives subtle structure to the interior.

OK let me finalize and write the code!

I just realized I should also handle the case where the canvas is not yet sized when the page loads. I'll size it on first load and on resize.

Let me also make sure the controls overlay doesn't interfere with mouse events on the canvas.

For the controls, I'll use `pointer-events: none` on the container and `pointer-events: auto` on the button.

Alright, writing the file now. I'll combine everything into one clean, complete implementation.

Actually let me reconsider the worker approach. Creating a blob URL worker might not work in all environments (especially with file:// protocol). But since we're serving from a local file system, it should work in modern browsers. Let me also add a fallback... no, let's keep it simple. The blob worker should work fine.

Let me write the code now.

Here's another thought: I should handle the case where the window is resized. On resize, I'll update the canvas size and re-render.

But to avoid re-rendering on every resize event (which fires rapidly), I'll debounce it.

OK let me just write the complete implementation now. I'll aim for clean, well-commented code.

Let me think about one more thing: the zoom speed. On each wheel tick, I'll zoom by a factor (e.g., 15%). The zoom is centered on the cursor position.

```javascript
const zoomFactor = 0.85; // for zoom in (negative deltaY)
const zoomFactor = 1.15; // for zoom out (positive deltaY)

// When zooming in:
const xRange = xmax - xmin;
const yRange = ymax - ymin;
const cx = xmin + (mouseX / canvas.width) * xRange;
const cy = ymin + (mouseY / canvas.height) * yRange;

const newRangeX = xRange * zoomFactor;
const newRangeY = yRange * zoomFactor;

xmin = cx - newRangeX / 2;
xmax = cx + newRangeX / 2;
ymin = cy - newRangeY / 2;
ymax = cy + newRangeY / 2;
```

This zooms towards the cursor position. When zooming in (zoomFactor < 1), the new range is smaller and centered on the cursor position.

For zoom out, zoomFactor > 1.

OK let me write the complete code now. This is going to be a substantial file.

Note: I need to make the wheel event non-passive to be able to call preventDefault. In modern browsers, wheel events are passive by default. I'll use `{ passive: false }` in the event listener.

Let me write the file now.

Let me launch the browser to view the file and check the initial output.

The CSP is blocking the Worker from a blob URL. I need to use a different approach. Options:

1. Use a different CSP approach - but I can't control the CSP headers since this is in a sandbox.
2. Use inline computation with requestAnimationFrame/time-slicing instead of a Worker.
3. Use the `data:` scheme for the worker - but that won't work either with CSP.

Let me try the approach of using an inline worker with a different method. Actually, I could try using `URL.createObjectURL` with a worker created from an inline function... but that's what I'm doing.

Wait, the CSP says `worker-src 'none'`. The sandboxed environment blocks workers. I need to fall back to doing computation on the main thread, but I'll chunk it with requestAnimationFrame to keep it responsive.

Let me rewrite without workers. I'll use requestAnimationFrame to render in chunks.

Let me think about a good chunked rendering approach:

1. Divide the canvas into tiles (e.g., 32x32 pixel blocks)
2. Render tiles one by one using requestAnimationFrame
3. After each tile, call requestAnimationFrame to continue
4. This way, the UI stays responsive and wheel/drag events can interrupt

For responsiveness during rendering:
- Keep a queue of tiles to render
- On each animation frame, render several tiles (maybe 10-20 depending on performance)
- Check if a new render request came in (via zoom/pan), and if so, abort current render

Let me rewrite without the Worker.

I need to fix the zx2/zy2 issue in the colorFromIter call. I'm passing `result.zx2` twice instead of `result.zx2, result.zy2`. And I need to make sure those properties are returned from `renderPixel`.

It's still showing the old page! The browser is caching the page. I need to reload the browser.

Good, the new page is loaded and it says "Rendering…". The CSS "Render error" is gone. Let me wait for the rendering to complete and take a screenshot. Let me check after a few seconds.

The rendering completed (status is empty). But I can't see the image since images are not supported. Let me check the console for errors. No errors shown. Let me also look for a bug I noticed earlier - in the `colorFromIter` call I'm passing `result.zx2` twice instead of `result.zx2, result.zy2`. Let me check the code.

Looking at my code:
```javascript
colorFromIter(r, result.n, maxIter, result.zx2, result.zx2, result.zx, result.zy);
```

Wait, `renderPixel` returns `{ n, zx2, zy2, zx, zy }`. But I'm passing `result.zx2` twice and missing `result.zy2`. This could produce incorrect colors. Let me fix this.

Also, I just noticed something odd in my code - `colorFromIter` signature takes `(r, n, maxIter, zx2, zy2, zx, zy)` but in the render chunk I'm calling it with `result.zx2` for both zx2 and zy2. Let me fix this.

Also, there might be an issue with the imageData slice approach. Let me review the chunk rendering code.

The issue: `new ImageData(pixels.slice(startRow * pw * 4, endRow * pw * 4), pw, endRow - startRow)` - this creates an ImageData with a specific slice. But `putImageData` expects the data to be in the right format. Let me verify this works correctly.

Actually, `ImageData` constructor: `new ImageData(data, width, height)` where `data` is a Uint8ClampedArray. The `slice` method returns a new Uint8ClampedArray. So this should work.

But wait - the `pixels` is a `Uint8ClampedArray` wrapping an `ArrayBuffer`. The `slice` method should work fine on it.

Let me also check if there's a bug in how I'm computing the y coordinate. In the chunk:
```javascript
const cy = ymin + (py / ph) * ySpan;
```
This is correct - py ranges from 0 to ph-1.

Let me fix the bugs and also check for any other issues.

The main issue is the `result.zx2` being passed twice. Let me fix that.

Also, I should double check that I'm handling the dpr scaling correctly. The `putImageData` call uses `startRow / dpr` as the y position, but imageData's height is in pixels (device pixels), so the y should be in device pixel coordinates... Actually no, `putImageData` puts the image data at the specified position in the current canvas coordinate space. Since we have `ctx.setTransform(dpr, 0, 0, dpr, 0, 0)`, the coordinates are in CSS pixels. So if we want to put image data at row `startRow` (device pixels), we need to divide by dpr to get CSS pixels.

Hmm, this is tricky. Let me think about it more carefully.

The canvas is `canvas.width = width * dpr`, `canvas.height = height * dpr` where `width` and `height` are CSS pixels.

We set the transform to `dpr, 0, 0, dpr, 0, 0`, which means all drawing operations use CSS pixel coordinates but draw at device resolution.

`putImageData(imageData, x, y)` puts the image data at canvas pixel coordinates (not transformed). The function ignores the current transform.

So if I call `ctx.putImageData(imageData, 0, startRow / dpr)`, it's placing the image data at canvas pixel position `(0, startRow/dpr)`. But the imageData has height `endRow - startRow` rows in device pixels. So it would be placed starting at `startRow/dpr` CSS pixels from the top, which is `startRow` device pixels from the top. That's correct!

Wait, actually `putImageData` uses the canvas's backing store coordinates (device pixels), not the CSS coordinates affected by the transform. So `putImageData(imageData, 0, startRow/dpr)` would place it at `startRow/dpr` in the backing store, which is wrong.

Let me re-check. According to MDN: "The putImageData() method of the Canvas 2D API paints data from the passed ImageData object onto the canvas. If a dirty rectangle is provided, only the pixels from that rectangle are painted. This method is not affected by the canvas transformation matrix."

So `putImageData` ignores the transform and works in the canvas coordinate system, which is the backing store dimensions (width × height in device pixels). So the coordinates passed to `putImageData` should be in device pixels.

So I should call `ctx.putImageData(imageData, 0, startRow)` not `startRow / dpr`.

Let me fix this.

Also, for the initial canvas setup, `ctx.setTransform(dpr, 0, 0, dpr, 0, 0)` is correct for normal drawing operations, but `putImageData` ignores it. So I need to use device pixel coordinates for putImageData.

Let me fix these issues now.

I see several bugs:

1. `colorFromIter(r, result.n, maxIter, result.zx2, result.zx2, result.zx, result.zy)` - passing `result.zx2` twice, missing `result.zy2`. Should be `result.zx2, result.zy2`.

2. `ctx.putImageData(imageData, 0, startRow / dpr)` - `putImageData` ignores the transform and works in canvas backing store coordinates (device pixels). So it should be `ctx.putImageData(imageData, 0, startRow)` not `startRow / dpr`.

3. Also the `drawImage` for the offscreen canvas during drag: the offscreen canvas is in device pixel dimensions (pw × ph), but `drawImage` respects the transform. Since we have `ctx.setTransform(dpr, 0, 0, dpr, 0, 0)`, drawing the offscreen canvas at position `(dx, dy)` where dx/dy are in CSS pixels should work because the offscreen canvas is in device pixels and `drawImage` will scale it down by dpr. Hmm, that's actually a problem too.

Wait, let me think about this more carefully.

The `offscreenCanvas` has dimensions `pw × ph` (device pixels). When I call `ctx.drawImage(offscreenCanvas, dx, dy)` with the transform `dpr` scale, it will:
1. Map the CSS position (dx, dy) to device position (dx*dpr, dy*dpr)
2. Draw the offscreenCanvas at device position (dx*dpr, dy*dpr) with dimensions (pw, ph) in device pixels
3. Which corresponds to CSS position (dx, dy) with CSS dimensions (width, height)

So this should be correct actually. The offscreen canvas has the same device pixel dimensions as the on-screen canvas. When drawn with the dpr transform, it maps correctly to CSS pixels.

Wait no. `drawImage` works like: the source image (offscreenCanvas) has its own dimensions. When you call `drawImage(img, x, y)`, it draws the image at CSS coordinate (x, y) with its natural size in CSS pixels. But the transform scales it.

Actually, `drawImage` is affected by the transform. With `ctx.setTransform(dpr, 0, 0, dpr, 0, 0)`:
- `drawImage(offscreenCanvas, dx, dy)` draws the offscreenCanvas at CSS coordinate (dx, dy)
- The offscreenCanvas has width = pw (device pixels), but the transform scales everything by dpr
- So the image would be drawn at position (dx*dpr, dy*dpr) in device pixels with size (pw*dpr, ph*dpr) in device pixels
- This would be wrong! It would be scaled up by another dpr factor.

Actually wait, I need to reconsider. `drawImage` takes CSS coordinates (when using the 3-argument form). The source image's dimensions are used in CSS pixels. But the offscreenCanvas width is pw (device pixels). When the browser draws `drawImage(offscreenCanvas, dx, dy)`, it interprets the source as having size pw × ph in CSS pixels, then the transform scales it by dpr to device pixels. So the result would be pw*dpr wide in device pixels, which is wrong (should be pw).

Hmm, this is getting confusing. Let me think step by step.

For a canvas with `canvas.width = width * dpr` and CSS width = width:
- Without transform: drawing at (0,0) with size (width, height) in CSS pixels
- The browser auto-scales to fill the backing store

With `ctx.setTransform(dpr, 0, 0, dpr, 0, 0)`:
- A CSS coordinate (10, 10) maps to device coordinate (10*dpr, 10*dpr)
- `drawImage(offscreenCanvas, 0, 0)` - offscreenCanvas has pw = width*dpr device pixels
- The browser draws the source at CSS position (0,0) with its natural CSS size, which is (pw in CSS pixels)... 

Actually no. When you set a canvas's width/height attributes, those ARE the pixel dimensions. CSS width/height is just for layout. When you draw an image onto a canvas using drawImage, the source dimensions are in the source's own pixel dimensions.

OK let me just simplify this. Let me not use dpr at all for the offscreen canvas operations during drag. Instead, I'll save the image data at CSS resolution and draw at CSS resolution.

Actually, the simplest fix: change `putImageData(imageData, 0, startRow / dpr)` to `putImageData(imageData, 0, startRow)` since putImageData works in backing store (device pixel) coordinates.

And for the offscreen canvas during drag: since the offscreen canvas has the same dimensions as the display canvas (pw × ph), and we're drawing it with `drawImage` which IS affected by the transform... 

Let me think about this differently. The on-screen canvas has CSS size `width × height` and backing store size `width*dpr × height*dpr`. The offscreen canvas has `width*dpr × height*dpr`.

When I call `ctx.drawImage(offscreenCanvas, dx, dy)`, `drawImage` is affected by the transform. With `dpr` scale:
- The source image (offscreenCanvas) has dimensions `pw × ph` (device pixels)
- When drawn with `drawImage`, the source dimensions are interpreted in CSS pixels
- Then the transform scales by dpr, making the destination device size `pw*dpr × ph*dpr`
- But we want it to be `pw × ph` in device pixels!

So using `drawImage(offscreenCanvas, dx, dy)` with the dpr transform is WRONG. It would scale up by another factor of dpr.

To fix this, I should either:
1. Store the offscreen canvas at CSS resolution (width × height) and draw it without transform concerns
2. Use temporary transform of (1, 0, 0, 1, 0, 0) before drawImage, then restore

Option 1 is simpler. Let me change the approach: save offscreen at CSS resolution, and work with CSS resolution for the pixel buffer too.

Actually, the simplest approach is to just remove the dpr scaling entirely and just use 1:1 canvas (1 device pixel = 1 CSS pixel). On high-DPI displays, it won't be as sharp, but it will be much simpler.

Actually, let me keep the dpr but be more careful. Let me use a simpler approach:

1. Store pixel data at device resolution (pw × ph array)
2. Use `putImageData` which is NOT affected by transform, pass device pixel coordinates
3. For the offscreen canvas during drag: temporarily reset the transform to identity before drawImage

Let me fix all three bugs:

Bug 1: `result.zx2, result.zx2` → `result.zx2, result.zy2`
Bug 2: `startRow / dpr` → `startRow` (putImageData uses device coords)
Bug 3: During drag, reset transform to identity before drawImage, then restore

Actually for bug 3, since drawImage IS affected by transform, and the offscreen canvas is in device pixels, I need to either:
- Use identity transform during drag
- Or store at CSS resolution

Let me just use the identity transform approach for the drag phase.

Actually, looking more carefully, let me reconsider:

The offscreen canvas has `pw × ph` device pixels. When I draw it with `ctx.drawImage(offscreenCanvas, dx, dy)` and the current transform is `dpr` scaling:
- `dx` and `dy` are in CSS pixels
- The source image dimensions `pw × ph` are interpreted... 

Actually, MDN says: "The destination canvas coordinate system is used to specify the destination (x, y) and the width and height, not the source canvas coordinate system."

So `drawImage(source, dx, dy)` draws the source at destination coordinates (dx, dy). Since we have `ctx.setTransform(dpr, 0, 0, dpr, 0, 0)`, the destination coordinates (dx, dy) are in the transformed space, which means:
- Device position = (dx * dpr, dy * dpr)

But the source image's width/height are also in the destination coordinate space (CSS pixels). With the transform applied, the destination width/height of the drawn image would be `pw / dpr × ph / dpr` in CSS pixels, which maps to `pw × ph` in device pixels. 

Wait, I think I'm overcomplicating this. Let me just test.

Actually, I think the way `drawImage` works with transforms is:
- The source is drawn at position (x, y) in the current user coordinate system (CSS pixels with our transform)
- The source's natural width and height define the size in the current user coordinate system

So with transform of dpr scale:
- Position (dx, dy) in CSS → device (dx*dpr, dy*dpr) ✓
- Source dimensions (pw, ph) in CSS → device (pw*dpr, ph*dpr) ✗ (should be pw, ph)

So it IS wrong. The source would be drawn at dpr times too large.

To fix this during drag, I need to either:
1. Temporarily set transform to identity before drawImage, then restore
2. Create the offscreen canvas at CSS resolution instead

Let me go with option 1 since it's simpler. During drag:

```javascript
ctx.save();
ctx.setTransform(1, 0, 0, 1, 0, 0);
ctx.drawImage(offscreenCanvas, dx * dpr, dy * dpr);
ctx.restore();
```

This would draw the offscreen canvas (device pixels) at device position (dx*dpr, dy*dpr), maintaining the correct scale.

Or, I could just store the image at CSS resolution (width × height) and not worry about dpr for the offscreen canvas.

Let me simplify. I'll store the rendered image at CSS resolution for the offscreen canvas, and draw it during drag without any transform issues.

Actually, let me take a different approach. Let me just save `getImageData` from the visible canvas (CSS coordinates) and use that for drag. The visible canvas after rendering will have the correctly rendered pixels at CSS resolution (because of the dpr transform on all drawing operations except putImageData).

Wait, the problem is that `putImageData` is placing data at device pixel positions, and the canvas already has those device pixels correctly set. When we then do `getImageData(0, 0, width, height)` (CSS coordinates), it gets the data at CSS resolution, which is a scaled version of the device pixels. That could cause quality loss.

OK, this is getting really complex. Let me take a MUCH simpler approach: just don't use dpr at all. Use 1:1 canvas pixel to CSS pixel. This avoids all these complications. On high-DPI displays it won't be as crisp, but for a fractal renderer that's perfectly acceptable.

Actually, you know what, let me keep dpr but just fix the bugs and handle the offscreen canvas properly. Let me fix:

1. `result.zx2, result.zx2` → `result.zx2, result.zy2`
2. `startRow / dpr` → `startRow` (putImageData uses device pixel coords)
3. For drag: create the offscreen canvas at CSS resolution (width × height) and draw the rendered data at CSS resolution. This means I need to either:
   a. Maintain a second copy of the image data at CSS resolution, or
   b. Use drawImage which auto-scales

Actually, the simplest fix for the drag: when saving the offscreen copy, use `ctx.drawImage(canvas, 0, 0)` onto a CSS-sized canvas. The browser will handle the conversion.

Or even simpler: during drag, use `getImageData` and `putImageData` instead of `drawImage`. Since `putImageData` is not affected by transforms.

Actually, the absolute simplest: during drag, save the rendered data as an ImageData at the canvas's backing store size, and use `putImageData` to draw it during drag (which uses device coordinates).

But I need to know the offset in device pixels. The mouse coordinates are in CSS pixels, so `dx` and `dy` are in CSS pixels. I need to convert to device pixels: `dx * dpr, dy * dpr`.

Let me just use this approach:

```javascript
// After render completes:
const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
// This gets all device pixels

// During drag:
ctx.putImageData(imageData, dx * dpr, dy * dpr);
```

But `getImageData` also returns data at the backing store resolution and uses device coordinates. So `ctx.getImageData(0, 0, canvas.width, canvas.height)` gets the full backing store.

Then `ctx.putImageData(imageData, dx * dpr, dy * dpr)` places it at the device position (dx*dpr, dy*dpr).

This should work! Let me implement this approach.

Actually, I realize `putImageData` just replaces pixels at the specified device coordinate position. It doesn't do any scaling or blending. So if I save the full canvas backing store as an ImageData, and then during drag I put it at an offset, it would be clipped at the edges, showing the image shifted by the offset. This is exactly what we want.

Let me use this approach. I'll save the full backing store pixels and use putImageData with device pixel offsets during drag.

OK, final fix plan:

1. Fix `result.zx2, result.zx2` → `result.zx2, result.zy2`
2. Fix `startRow / dpr` → `startRow` 
3. Replace offscreenCanvas approach with ImageData saved at device resolution
4. During drag, use putImageData with device pixel offsets

Let me rewrite the relevant parts.

Good, the bugs are fixed. Let me reload and check.

It's rendering now. Let me wait a moment and screenshot to see if the render completes and the fractal appears. The console only has the iframe warning, no errors. Let me wait a bit.

The rendering completed. The "Rendering…" text is gone. The browser doesn't support image display so I can't see it visually, but no JavaScript errors are present. Let me try to do some interaction tests.

Let me click on the canvas to test drag, and try wheel zoom.

First, let me click somewhere on the canvas to test if the drag works.

Actually, let me also check if the coord text updates when I drag.

Let me first just inspect the state more carefully by checking console output.

Actually, I can interact with the browser tools. Let me try clicking and dragging on the canvas, and then zooming with wheel.

But first, let me note that images are not supported in this environment, so I can't verify the visual output. Let me focus on testing interactions and checking for errors.

Let me start by inspecting the page state and then do some interactions.

Interesting. The drag started and the coords changed to "Center: -2.250000, -1.312500" which seems like the center is at the top-left of the initial view. Wait, that doesn't seem right. Let me think about this.

Initial bounds: xmin = -2.25, xmax = 1.25 (x range = 3.5)
The aspect ratio: if width = 1200, height = 800, then y range = 3.5 * 800/1200 = 2.333...
So ymin = -1.1667, ymax = 1.1667

Center after drag: The drag went from (200, 300) to (300, 350), so dx = 100, dy = 50.

During drag, the coords show: Center: -2.250000, -1.312500

Wait, -2.25 is the initial xmin (left edge), not the center. That seems wrong. Let me re-check the formula.

In onDragMove:
```javascript
const nx = dragBounds.xmin + (dx / width) * xr;
```
With dragBounds.xmin = -2.25, dx = 100, xr = 3.5, width = 1200:
nx = -2.25 + (100/1200) * 3.5 = -2.25 + 0.2917 = -1.9583

Hmm, that's not -2.25. Let me think... Actually, if the drag just started and the first drag move happened, dragStartX might be somewhere around 200 (the starting point). The actual delta is 100 (from 200 to 300).

But wait, the "Rendering…" text is showing again, which means the drag ended and a new render started. The coords show Center: -2.250000, -1.312500. 

Let me calculate: if dx = 100 (for the end of drag):
bounds shift: dx/width * xr = 100/1200 * 3.5 = 0.2917
new xmin = -2.25 - 0.2917 = -2.5417

Wait, the formula is:
```javascript
xmin = dragBounds.xmin - (dx / width) * xr;
```

So with a positive dx (drag right), xmin decreases (moves left). That means the view shifts left when dragging right, which is the OPPOSITE of what I intended.

Hmm, let me re-check my logic. During drag, the image offset is `(dx, dy)` where dx = pos.x - dragStartX. So if the mouse moves right (dx positive), the image is drawn at position (dx, dy) to the right. This means the image appears to move right with the cursor. This reveals new content on the LEFT side of the screen.

When the drag ends, the new bounds should be: the bounds that correspond to what the user sees. If the image moved right by dx pixels, then the content now visible on the canvas has shifted. 

If the old image at position (0,0) is now drawn at position (dx, 0), then:
- What was at pixel position 0 (left edge) in the old image is now at pixel position dx
- What is at pixel position 0 now shows content that was at pixel position -dx in the old image
- In complex coordinates, that means: xmin_new = xmin_old + (-dx/width) * xr = xmin_old - (dx/width)*xr

So xmin_new = xmin_old - (dx/width) * xr. With dx=100 (drag right), xmin_new = -2.25 - 0.2917 = -2.5417.

That means the view shifted left when dragging right. The new center is at roughly -1.7917, which is to the LEFT of the original center (-0.5).

Wait, that doesn't feel right. Let me reconsider.

Actually, in most image viewers / map apps, when you drag right:
- The content moves right with your cursor
- You see new content on the LEFT

So dragging right reveals content to the LEFT. In our case, that means the viewport has shifted LEFT in complex space. So xmin and xmax should both DECREASE (shift left).

With dx = 100 (drag right by 100px):
new xmin = old xmin - (dx/width)*xr = -2.25 - 0.2917 = -2.5417
new xmax = old xmax - (dx/width)*xr = 1.25 - 0.2917 = 0.9583

Center = (new xmin + new xmax) / 2 = (-2.5417 + 0.9583) / 2 = -0.7917

So the view shifted left. But the coords show "Center: -2.250000" which doesn't match.

Wait, the coords shown were during the drag move (not after). Let me look at the code again.

In onDragMove:
```javascript
const nx = dragBounds.xmin + (dx / width) * xr;
```

With dx = pos.x - dragStartX = 300 - 200 = 100:
nx = -2.25 + (100/1200) * 3.5 = -2.25 + 0.2917 = -1.9583

But the display shows -2.250000. That's odd. Maybe the drag ends and re-renders immediately, and the coords shown are from the zoom/render start.

Actually, looking more carefully: the console shows "Rendering…\nCenter: -2.250000, -1.312500". The "Rendering…" means a new render started. The coords are from... let me check what sets the coords text.

The coord text is set in onWheel (for zoom) and onDragMove (during drag). After drag ends, render() is called but coords are not explicitly set. So the coords shown might be from a previous zoom or something.

Hmm, actually the "Center: -2.250000, -1.312500" is suspicious. -2.25 is the initial xmin. Let me check: the coord in onDragMove is:

```javascript
const nx = dragBounds.xmin + (dx / width) * xr;
```

If the mousemove event fires BEFORE the drag starts (because isDragging is checked at the beginning), then dx could be computed but isDragging would be false so it wouldn't execute. Let me check onDragMove:

```javascript
function onDragMove(e) {
  if (!isDragging) return;
  ...
}
```

So this only updates coords when dragging. The coord value of -2.25 is suspicious. 

Wait, maybe the browser tool's drag action triggers the mousedown, then mousemove, then mouseup. Let me check if the drag action is working correctly.

Actually, I wonder if the coords shown are from a wheel zoom event triggered by the drag somehow, or if the drag function computed something incorrectly.

Let me try a different approach. Let me interact more carefully.

Actually, I should check the actual coords after the drag. The browser DOM shows:
"⟲ Reset view\nRendering…\nCenter: -2.250000, -1.312500"

Hmm, let me calculate: ymin initial is roughly -1.1667 (if height=800). But -1.3125 doesn't match. Let me see what size the viewport is.

Actually, the viewport might be different dimensions. In the browser tool, the viewport is 1200x800 (as mentioned in the docs). So width=1200, height=800.

Initial: xmin = -2.25, xmax = 1.25, xr = 3.5
yr = 3.5 * 800 / 1200 = 2.333...
ymin = 0 - 2.333/2 = -1.1667
ymax = 0 + 2.333/2 = 1.1667

The coord "Center: -2.250000, -1.312500" doesn't match these initial values. -2.25 is xmin, and -1.3125 is... let me check: it's exactly -21/16. 

Wait, could this be from a zoom event? If the wheel was scrolled before the drag?

Actually the coord text is displayed in the DOM. Let me re-read the display more carefully.

It says: "⟲ Reset view\nRendering…\nCenter: -2.250000, -1.312500"

But the status and coords are in separate `<span>` elements. Let me not overthink this and just try another interaction.

Let me try to click the Reset button and check the output.

I clicked the Reset button. The "Rendering…" text is gone now, but "Center: -2.250000, -1.312500" is still there. Wait, that's from the coords element, and it shouldn't be there after a reset because `coordsEl.textContent = '';` is called in `resetView()`. 

But it's still showing. Let me trace through the code. Actually, maybe the rendering is happening and the coordinates are from a wheel event... 

Wait, I clicked the Reset button at position (40, 760). The button is at the bottom-left. The coordinates shown are "Center: -2.250000, -1.312500". 

Actually, when the page re-renders after reset, the coords should be cleared. But they're not. Let me check if there's a bug.

Looking at resetView():
```javascript
function resetView() {
    if (isRendering) renderAborted = true;
    xmin = initialXmin;
    xmax = initialXmax;
    ymin = initialYmin;
    ymax = initialYmax;
    coordsEl.textContent = '';
    render();
  }
```

This clears coords. But maybe the render still shows "Rendering…" in status and the coordinates from a previous event are still visible in the DOM snapshot.

Wait, looking at the DOM output: "⟲ Reset view\nCenter: -2.250000, -1.312500"

The "\n" seems like the DOM shows multiple text nodes. The button text "⟲ Reset view", then status (empty), then coords ("Center: -2.250000, -1.312500").

But after reset, coords should be cleared. Unless the mouseup event for the click fired a drag end and set coords... No, the click is a mouse click on the button, not on the canvas.

Wait, I think the issue is that the coordinates -2.250000, -1.312500 were set from a previous action (maybe a zoom or drag), and when I click Reset, the coords should be cleared. But the DOM snapshot shows them still present. Maybe the click didn't actually fire the reset?

Let me check: the button is at the bottom of the page. Position (40, 760) - the viewport is 800px tall, 1200px wide. So (40, 760) is near the bottom-left corner, which should be where the button is.

But wait, the Reset button text says "⟲ Reset view" which includes the ↻ character. Let me check if the click hit the button.

Actually, after clicking, it says "Rendering…" is no longer shown, which means the reset function worked (it calls render which shows "Rendering…" briefly). But the coords still show. Hmm, but the DOM snapshot might be taken before the coords are cleared.

Actually, the DOM output shows "Center: -2.250000, -1.312500" which suggests the coords were not cleared. Let me look at this more carefully.

Wait, I bet the issue is that the rendering from the previous action (drag) is still running and it now shows "Rendering…" from before. Then I click Reset, which calls `renderAborted = true` on the old render, and starts a new render. During the new render, the coords should be cleared...

But the DOM still shows coords. Maybe the issue is that the reset happened but a subsequent mousemove or wheel event set the coords again before the DOM snapshot.

Let me try a simpler test: just reload and inspect the initial state.

After reload, it shows "Rendering…" which is expected. Let me wait for the rendering to finish and then check the state.

The render finished. No "Rendering…" text. Now let me test a zoom interaction. Let me wheel zoom on the canvas and check if it works.

The scroll action uses delta, not absolute x,y. Let me look at the browser tool parameters again.

The browser tool has: action, x, y, delta, toX, toY, text

For scroll, it uses delta, not x,y. Let me check the schema again.

Actually looking at the parameters: scroll action has no specific parameters listed beyond the common ones (action, x, y, delta, etc.). Let me try with delta.

The wheel zoom worked! After scrolling (negative delta = zoom in), the rendering started and the coords show "Center: -2.250000, -1.166667".

Wait, that's the bottom-left corner of the initial view. -2.25 is xmin and -1.166667 is ymin. The cursor was at (600, 400) which is the center of the viewport. The center of the complex plane is at (-0.5, 0). But the coord shows (-2.25, -1.1667). 

Let me check: the zoom calculation should be correct. The factor for negative delta: `1 / 1.12 ≈ 0.8929`. So we zoom in by ~10.7%.

With the cursor at (600, 400) (center of viewport), the complex position under cursor is:
cx = -2.25 + (600/1200) * 3.5 = -2.25 + 1.75 = -0.5
cy = -1.1667 + (400/800) * 2.333 = -1.1667 + 1.1667 = 0

So the cursor is at (-0.5, 0), which is the center. After zoom by factor 0.8929:
new xr = 3.5 * 0.8929 = 3.125
new yr = 2.333 * 0.8929 = 2.083

xmin = -0.5 - 3.125/2 = -2.0625
xmax = -0.5 + 3.125/2 = 1.0625

So the center should still be (-0.5, 0), not (-2.25, -1.1667). 

But the DOM shows "Center: -2.250000, -1.166667". That's the old center? Or maybe the coord update happens before the bounds are recalculated?

Let me re-check onWheel:
```javascript
coordsEl.textContent = `Center: ${cx.toFixed(6)}, ${cy.toFixed(6)}`;
render();
```

Here, cx = -0.5, cy = 0 (the cursor position). But the DOM shows -2.250000, -1.166667. That's not right.

Unless... the coordinates are being updated somewhere else after the wheel event. Like during rendering, another event fires.

Actually wait, I need to re-check: the "Rendering…" text and coords might be from the previous state. The DOM output might just show "Rendering…" from the current render and the coords from a previous event.

Actually, the scroll action triggered a render. The status shows "Rendering…". The coords show "Center: -2.250000, -1.166667". 

Hmm, -2.250000 is exactly xmin, and -1.166667 is... let me calculate: if ymin = -1.166667... Actually, 2.333/2 = 1.166666..., so ymin = -1.166667. Yes, that's the initial ymin.

So the coords show the bottom-left corner of the initial view! Not the cursor center.

Maybe there's a bug in how the coords are set. Let me check: the `onWheel` function sets `coordsEl.textContent = ...` with `cx` and `cy` being the cursor position in complex space. But after the scroll, the DOM shows xmin and ymin values.

Wait, could it be that the scroll action triggered both a wheel event AND a mousemove event (which triggers onDragMove)?

Actually, the scroll action sends a wheel event to the page. After that, the page starts rendering. The DOM snapshot might include the coords that were set during the scroll. But the cx, cy values should be (-0.5, 0), not (-2.25, -1.1667).

Unless the scroll happened at position (0, 0) which is the top-left corner of the viewport, and the complex position there is (-2.25, -1.1667). But I specified x=600, y=400.

Wait, maybe the browser tool's scroll action uses a different coordinate system, or maybe it sends the wheel event at a different position. Let me try the scroll again with a different position.

Actually, let me re-read the scroll parameters. The schema says: `scroll` has parameters `x` and `y` which default to the center of the viewport if not provided. And `delta` for the scroll amount.

I specified x=600, y=400 which is the center. But maybe the browser tool doesn't accept x and y for scroll? Let me check the schema again.

Looking at the browser tool schema, the scroll action has no specific parameters. It accepts the common ones: x, y, delta, etc. But scrolling typically just uses delta and the current pointer position.

Hmm, maybe the scroll action triggered the wheel event at (0, 0) because x and y aren't accepted for scroll? Let me try with just delta.

Actually, looking at the browser tool parameters more carefully: it says `scroll` accepts x, y, and delta. But maybe the x and y are not being used for wheel position.

Let me try a different approach. Let me use inspect to check the console for any errors.

The rendering finished. The coords still show "Center: -2.250000, -1.166667". This is definitely buggy - these are the initial xmin/ymin values, not the actual center.

Let me trace through the code to find the bug. The `onWheel` function:

```javascript
function onWheel(e) {
    e.preventDefault();
    if (isRendering) {
      renderAborted = true;
    }
    const rect = canvas.getBoundingClientRect();
    const mx = e.clientX - rect.left;
    const my = e.clientY - rect.top;
    if (mx < 0 || mx > width || my < 0 || my > height) return;

    const factor = e.deltaY > 0 ? 1.12 : 1 / 1.12;

    const xr = xmax - xmin;
    const yr = ymax - ymin;
    const cx = xmin + (mx / width) * xr;
    const cy = ymin + (my / height) * yr;

    const nxr = Math.min(xr * factor, 10);
    const nyr = Math.min(yr * factor, 10);

    xmin = cx - nxr / 2;
    xmax = cx + nxr / 2;
    ymin = cy - nyr / 2;
    ymax = cy + nyr / 2;

    coordsEl.textContent = `Center: ${cx.toFixed(6)}, ${cy.toFixed(6)}`;
    render();
  }
```

If `mx` and `my` are computed from `e.clientX` and `e.clientY`, and if the scroll action sends the wheel event at the center of the viewport (600, 400), then:
- mx = 600, my = 400 (if rect.left and rect.top are 0)
- cx = -2.25 + (600/1200) * 3.5 = -2.25 + 1.75 = -0.5
- cy = -1.166667 + (400/800) * 2.333 = -1.166667 + 1.166667 = 0

So cx = -0.5, cy = 0. Then coords should show "Center: -0.500000, 0.000000", not "-2.250000, -1.166667".

Something is wrong. Maybe the scroll action doesn't actually set e.clientX/e.clientY properly, or the coordinates are being set from the drag move handler.

Wait, the DOM shows the coords even after the render completes. If the coords were set from the wheel handler to "Center: -0.500000, 0.000000", they wouldn't show -2.25.

Could the coordinates be from something else? Let me check if there's another code path that sets the coords.

Looking at the code, coordsEl.textContent is set in:
1. `onWheel`: `Center: ${cx.toFixed(6)}, ${cy.toFixed(6)}`
2. `onDragMove`: `Center: ${nx.toFixed(6)}, ${ny.toFixed(6)}`
3. `resetView`: cleared to ''

Hmm, but the value shown is xmin and ymin. That's suspicious. 

Wait, I think I might have the domain coordinates swapped. Let me double-check: in the drag move handler:
```javascript
const nx = dragBounds.xmin + (dx / width) * xr;
```

If dragBounds is undefined (not dragging), this code won't execute. So coords must come from the wheel handler.

But why does cx = -0.5 show up as -2.25? Could the scroll action not actually send x=600, y=400?

Let me just try another scroll at the center of the viewport and see what happens.

Actually, let me also check: maybe the `e.clientX` and `e.clientY` from the browser tool's scroll are at (0, 0). The scroll might not support custom x/y for the wheel event.

Let me try to do a more targeted inspection. Let me use `inspect` to see the canvas content more carefully, or try to add some debugging.

Actually, the fact that coords show -2.25 and -1.16667 suggests that the mouse position used in the calculation is (0, 0). Because:
- cx = xmin + (0/width) * xr = xmin = -2.25
- cy = ymin + (0/height) * yr = ymin = -1.166667

Yes! The wheel event seems to be firing at position (0, 0) - the top-left corner. So the browser tool's scroll action might not support specifying the wheel position, or the x/y parameters for scroll are wrong.

Let me just accept this limitation and test zooming differently. Let me try scrolling without specifying x,y (which defaults to center).

Hmm, it shows "Center: -3.812500, -2.208333". Let me calculate:
- mx = clientX - rect.left. If the wheel fires at the center: 600, 400.
- But the result shows values way beyond -2.25.

Wait: -3.8125, -2.208333. These are less than (more negative than) xmin and ymin.
-3.8125 < -2.25 (xmin)
-2.208333 < -1.166667 (ymin)

So the mouse position might be negative? Or maybe the scroll is applying the zoom to the wrong bounds.

Actually wait, let me reconsider. Maybe the scroll action fires the event at a position that's NOT at x=600,y=400. Let me look at the values again:

If the event fires at the center (600, 400):
cx = -2.25 + 600/1200 * 3.5 = -0.5
cy = -1.166667 + 400/800 * 2.333 = 0

Hmm, but the result shows -3.8125. Let me think about this differently.

Wait, I just realized: the browser tool said it uses a 1200×800 viewport. But the scroll's x and y might be the viewport coordinates. And I set x=0, y=-400 initially which was rejected. 

Let me check: if I don't specify x,y, does it default to (0,0)? And if it fires at (0,0):
cx = -2.25 + 0/1200 * 3.5 = -2.25
cy = -1.166667 + 0/800 * 2.333 = -1.166667

But the result is -3.8125, not -2.25. So the coordinates are even more negative.

Wait, let me re-check: after the first scroll (which I did with x=600,y=400), the bounds changed. Then the second scroll (without position) applies to the already-zoomed bounds.

First scroll (zoom in at center, factor 0.8929):
xmin = -0.5 - 3.125/2 = -2.0625
xmax = -0.5 + 3.125/2 = 1.0625
ymin = 0 - 2.083/2 = -1.0415
ymax = 0 + 2.083/2 = 1.0415

Second scroll at the center (600, 400):
Wait, but I see -3.8125. That's way more negative than even the original -2.25. 

Hmm, actually, maybe the second scroll happened at (0,0) because the first scroll's wheel event was at (0,0) too. Let me re-check.

First scroll with x=600,y=400 gave coords: Center: -2.250000, -1.166667
This means the event position was (0,0), not (600, 400)! Because cx = -2.25 + 0/1200*3.5 = -2.25.

So the browser tool's scroll action ignores x and y for the wheel event position, and always fires at the current pointer position (which is (0,0) initially? Or wherever the pointer was last).

Actually, maybe the pointer starts at (0,0) and the first scroll fires there. Then after scrolling, it stays at... Actually, maybe the pointer is at some position and the scroll uses that.

Let me try a different approach - let me first use a click at a specific position to move the pointer there, then scroll.

But this is taking too long. Let me check that the core functionality works. Let me try reset first.

OK, the reset button click didn't seem to clear the coords. The coords still show -3.812500, -2.208333. But maybe the click hit the canvas instead of the button, or the rendering hasn't started yet.

Wait, the DOM shows "⟲ Reset view" without "Rendering…", which means the render completed. But the coords are still showing. 

After reset, `coordsEl.textContent = '';` should clear them. But they're not cleared. Let me check if there's a race condition.

Actually, maybe the click happened on the canvas (position 40, 760 might be within the canvas if the canvas fills the screen). The button is positioned at the bottom-left, but maybe it's not at exactly (40, 760). Let me check the button position.

The button is in `#controls` which has `position:absolute; left:16px; bottom:16px`. So the button should be at the bottom-left, around (16, 770) or so if the viewport is 800px tall. At (40, 760), it might be hitting the canvas instead.

Let me click more precisely on the button - maybe at (20, 775) which should be within the button area.

Actually, looking at the result: "⟲ Reset view" is shown (the button text), and no "Rendering…" which means either:
1. The click hit the button and reset worked (render finished)
2. The click hit the canvas and started a drag (render finished from previous state)

I think the coords being shown is because after reset, the render starts and runs chunk by chunk, and a requestAnimationFrame might fire before the coord text is processed, or there's some other timing issue.

But looking at the code, `coordsEl.textContent = '';` is called BEFORE `render()`, so the coords should be empty at the start of the render. Unless there's another event handler that sets them during rendering.

Wait, I just realized: the DOM output in the browser tool might be stale - it shows the state at the time the previous action completed, not necessarily the current state.

Let me try to reload and check the clean state more carefully.

Let me wait for the rendering to complete and inspect the clean state.

Good, the render completed and no coords are shown (status is empty). The initial state looks clean. Let me now try a wheel zoom by first clicking on the canvas to set focus, then scrolling.

Let me click at the center of the canvas first.

OK, clicking on the canvas at (600, 400) triggered a drag (mousedown) which set `renderAborted = true` on any existing render, then `e.preventDefault()` stopped propagation. The "Rendering…" appeared because after the click, the mousedown handler might have started a drag, but there's no corresponding mouseup yet.

Wait, actually: `onDragStart` sets `isDragging = true` and prevents default. Then when the click action ends (mouseup), it triggers `onDragEnd` which calls `render()`. But there was no movement, so dx=0 and dy=0, which means the bounds don't change and the render starts with the same bounds.

Actually, looking at `onDragEnd`:
```javascript
function onDragEnd(e) {
    if (!isDragging) return;
    isDragging = false;
    ...
    if (dragBounds) {
      ...
      render();
    }
  }
```

Even if dx=0 and dy=0, it still calls render() if dragBounds is not null. So a click on the canvas triggers a re-render. That's fine - it will re-render the same view. But it wastes time.

For a better UX, I should skip the render if dx and dy are both 0 (or very small). But this is a minor optimization, not a bug.

Let me wait for this render to complete and then try wheel zoom.

Render completed. Now let me try the wheel zoom. Let me click first at a specific position and then scroll.

Let me just check the key behavior without images. Let me verify the code logic is correct by reading through it again. Let me also check the drag offset direction - I think I might have gotten it backwards.

In the `onDragEnd` function:
```javascript
xmin = dragBounds.xmin - (dx / width) * xr;
```

If dx is positive (mouse moved right), xmin decreases. This means the view shifts left. But visually during drag, the image moved right (at position (dx, dy)), which means the content that was at x=0 is now at x=dx, revealing empty space on the left. This visually indicates we're seeing more to the LEFT. So shifting the bounds left is correct.

Wait no. Let me think about this step by step.

During drag:
- Saved image is drawn at (dx, dy) relative to the canvas
- dx = currentX - startX
- If mouse moves right (currentX > startX), dx > 0
- The saved image is drawn shifted right by dx pixels
- This means the content visible at position x=200 on canvas was originally at position x=200-dx in the saved image
- So we're seeing content that was originally to the LEFT
- This means the view has shifted LEFT

After drag:
- The new bounds should reflect that we shifted left
- xmin and xmax should be smaller (more negative) than before
- xmin_new = dragBounds.xmin - (dx/width) * xr ✓

So the direction is correct! The view shifts left when dragging right, which reveals content to the left.

Actually, wait. This is the opposite of how Google Maps works. In Google Maps, if you drag right, you see content to the RIGHT (the map moves left, revealing the right side). Let me reconsider.

In Google Maps convention: if you grab and drag to the right, the map moves with your cursor to the right, which means you see content that was to the LEFT (it comes from the left side of the screen into view). But Google Maps also scrolls the map in the direction of your drag - so if you drag right, you see more of the map to the right (the map center shifts right).

Hmm, actually, let me think about what happens in Google Maps:
1. You click and hold at the center of the screen
2. You drag your mouse to the right
3. The map shifts to the RIGHT, following your cursor
4. Now the center of the screen shows a point that was to the LEFT of the previous center
5. So the new center has shifted LEFT

Wait no. In Google Maps, if you drag right:
- The map appears to slide to the right under your cursor
- This means you now see more content on the RIGHT side of the map
- The center of the map has shifted RIGHT

Let me trace through: you start at the center of the screen. You drag the map to the right. Point A at the center of the screen moves right. The center of the screen now shows Point B, which was to the LEFT of Point A. So the center shifted left? That can't be right...

Actually, in Google Maps: if you grab and pull right, the map moves with your hand to the right. So the point under your cursor moves to the right. The new center (which was under your cursor at start) is now at the cursor position. But there's a new point under the cursor at the end - it's the point that was to the LEFT of the original center. So the center shifts LEFT.

Wait, I'm confusing myself. Let me think about it simply:

1. Center of screen shows Point C
2. You grab Point C (it's under your cursor)
3. You drag right by 100px (your cursor moves right by 100px)
4. Point C moves with your cursor - it's now 100px to the right of center
5. The new point under your cursor (at center of screen) is the point that was 100px LEFT of C
6. So the new center of the view is 100px LEFT of C
7. In complex coordinates: center shifts LEFT

So xmin and xmax should DECREASE (shift left) when dragging RIGHT. My formula is correct!

But wait, many implementations do it the other way. Let me think about what feels more natural.

Actually, in most image viewers and fractal explorers, when you drag right:
- The viewport seems to move right (you're looking at what's to the right)
- This is implemented as: the image moves left (showing more right-side content)
- So the bounds shift RIGHT

This is what I intuitively expect: drag right → see more of the right side. My implementation does the opposite (drag right → see more of the left side, because the image follows the cursor).

OK let me just change the drag direction to match the more common convention. I'll reverse the sign in the post-drag bounds update:

```javascript
xmin = dragBounds.xmin + (dx / width) * xr;
```

And during drag, draw the saved image at (-dx, -dy) instead of (dx, dy).

Wait, actually it depends on the convention. Both are valid. Let me just go with: the image follows the cursor during drag (what I have now - the saved image is drawn at the offset (dx, dy)). And after drag, the bounds match what's visible.

OK let me not change the behavior, just keep it as is. The drag behavior is fine as long as it's consistent - the image follows the cursor during drag, and the new render matches the visual position at the end of the drag.

Let me focus on verifying the zoom works correctly. Let me try a different approach - let me use inspect to check if there are any JS errors, and also check the logic again.

Actually, let me look at one more potential issue. In `onWheel`, I set the coords to the cursor position under the mouse. But the coords after the wheel action show xmin/ymin values (from my first test). Let me re-check if maybe the scroll action fires the event at (0,0).

Actually, I think the issue is that the browser tool's scroll action fires the wheel event at the current mouse position, which might be (0,0) if I haven't moved the mouse there. Let me try clicking at a position first and then scrolling.

Let me wait for this render. Let me try to fix the unnecessary re-render on click (no drag) issue, and also verify the zoom logic. Let me also check a potential issue - the overflow:hidden on body should prevent page scrolling.

Actually let me check something: the `onDragEnd` function. When there's no actual drag (dx=0, dy=0), it still triggers a render. This is because the mousedown+mouseup without movement still triggers onDragStart and onDragEnd, and the render is called unconditionally. Let me add a check to skip rendering if the drag distance is very small.

But more importantly, let me check the zoom math. Let me calculate manually what should happen:

Initial: xmin=-2.25, xmax=1.25, ymin=-1.166667, ymax=1.166667

After zoom at center (-0.5, 0) with factor 0.8929:
- xr = 3.5, yr = 2.333
- nxr = 3.5 * 0.8929 = 3.125
- nyr = 2.333 * 0.8929 = 2.083
- xmin = -0.5 - 3.125/2 = -2.0625
- xmax = -0.5 + 3.125/2 = 1.0625
- ymin = 0 - 2.083/2 = -1.0415
- ymax = 0 + 2.083/2 = 1.0415

Center should be (-0.5, 0). Good.

But the coords showed -2.25, -1.166667 after the first scroll test. This suggests the mouse was at (0,0) when the wheel event fired. So the browser tool doesn't support custom wheel positions.

Let me just accept this and check the zoom logic by verifying the console output after zoom. And then check if the reset works.

Let me also fix the unnecessary render-on-click issue to make testing faster.

Let me apply some fixes:
1. Skip render in onDragEnd if dx and dy are very small (no actual drag)
2. Make sure the drag visual feedback is correct

Let me also fix a potential issue: the click at (600, 400) triggers a mousedown (drag start) which aborts any running render, then starts a new render after mouseup even without movement.

Now let me also think about the zoom position issue. The scroll action from the browser tool doesn't seem to pass the position correctly. But in real usage with a mouse, the wheel event will have the correct clientX/clientY from the mouse position. So the zoom logic should be fine.

Let me also check that the initial view shows the complete cardioid and lobes. The initial bounds are: center (-0.5, 0), x range 3.5. This should show from x=-2.25 to x=1.25. The main cardioid extends from about -1.5 to 0.5 on the real axis, and the main bulb is centered around -0.75. The period-2 bulb is at -1, the period-3 bulbs are around -1.75 and -0.12. So x range of 3.5 should be plenty to show all of these.

For y: 3.5 * 800/1200 = 2.333, so y range from -1.167 to 1.167. The main cardioid extends from about -1 to 1 on the imaginary axis, so this is also sufficient.

Let me do a final check of the code to make sure everything is correct. Let me read the full file.

The code looks correct. Let me also check a potential issue I noticed: in the `dragBounds.xmin + (dx / width) * xr` part of `onDragMove`, this shows the "center" but actually it's computing xmin + something, which gives a coordinate that's on the left side of the canvas, not the center. Let me re-check.

Actually, looking at onDragMove:
```javascript
const nx = dragBounds.xmin + (dx / width) * xr;
```

If dx = 100 (dragged right by 100px), and the drag started at the center of the canvas (600, 400):
- The point that was at the center at drag start is now at pixel position 600+100 = 700 on the canvas
- Pixel 600 now shows a point that was at pixel 500 in the original
- That's xmin + 500/1200 * xr = -2.25 + 500/1200 * 3.5 = -2.25 + 1.458 = -0.792

But the formula gives: -2.25 + 100/1200 * 3.5 = -2.25 + 0.292 = -1.958

That's wrong! It shows xmin + dx_offset, which is the coordinate of the LEFT EDGE shifted by dx, not the center.

The center should be: (xmin + xmax) / 2 - (dx/width) * xr = -0.5 + 0.292 = -0.208? Or -0.5 - 0.292 = -0.792?

Wait, it depends on the convention. If the image shifted RIGHT (dx positive), meaning we see content from the LEFT, the center should shift LEFT:
newCenter = oldCenter - (dx/width) * xr = -0.5 - 0.292 = -0.792

So the coord display in onDragMove has a bug - it shows the wrong value. It should show the center, not xmin + dx/width * xr.

Let me fix this:
```javascript
const cx = (dragBounds.xmin + dragBounds.xmax) / 2 - (dx / width) * xr;
const cy = (dragBounds.ymin + dragBounds.ymax) / 2 - (dy / height) * yr;
```

Wait, actually, the point under the cursor at the mouse position (where dx, dy is the offset) would be:
The cursor is at pixel (dragStartX + dx, dragStartY + dy) = (currentX, currentY).
The complex coordinate at the cursor is:
cx = dragBounds.xmin + (currentX / width) * xr = dragBounds.xmin + ((dragStartX + dx) / width) * xr

But the display name says "Center" which is misleading if the cursor isn't at center. Let me just fix the coord label to say "Cursor" instead of "Center", or compute the actual center of the new view.

Actually, the coordinate that's most relevant for the user is the point under the cursor. During drag, that's the cursor position in complex space. After the drag, that point will be near the center (since the user dragged and then released, and the cursor might not be at the center).

Let me compute: if the user drags from (startX, startY) to (currentX, currentY), the complex coordinate at the current mouse position is:
cx = dragBounds.xmin + (currentX / width) * xr
cy = dragBounds.ymin + (currentY / height) * yr

That's the point under the cursor. Let me use that instead.

Actually wait, let me re-read the current code:

```javascript
const nx = dragBounds.xmin + (dx / width) * xr;
```

This computes: xmin + (currentX - startX) / width * xr = xmin + currentX/width * xr - startX/width * xr

That's not quite right for the cursor position. The cursor position is:
xmin + currentX/width * xr

But our formula is: xmin + currentX/width * xr - startX/width * xr

So it's off by startX/width * xr. That's wrong.

Let me fix the coord display to show the actual cursor position:
```javascript
const nx = dragBounds.xmin + ((pos.x) / width) * xr;
const ny = dragBounds.ymin + ((pos.y) / height) * yr;
```

Wait, but `pos` is already defined in onDragMove as `getPos(e)`. Let me use pos.x and pos.y directly.

Actually, let me use the more useful display: "Center" should be the center of the final view after drag, which is what the display shows in the output. Let me compute the prospective center:

```
newCenterX = (dragBounds.xmin + dragBounds.xmax) / 2 - (dx / width) * xr
```

This is what the center will be after the drag completes. Let me use this.

Let me fix the code.

Wait, `pos` is already defined in onDragMove as `getPos(e)`, so I can use `pos.x` and `pos.y` directly. But I also need to make sure `pos` is accessible inside the `if (dragBounds)` block. Let me check - yes, `const pos = getPos(e);` is at the top of `onDragMove`, and `dragBounds` check is after that, so `pos` is in scope.

Actually wait, I used `pos.x` and `pos.y` but the variable is named `pos`. Let me double-check the code:

```javascript
function onDragMove(e) {
    if (!isDragging) return;
    e.preventDefault();
    const pos = getPos(e);
    const dx = pos.x - dragStartX;
    const dy = pos.y - dragStartY;
    ctx.setTransform(dpr, 0, 0, dpr, 0, 0);
    ctx.clearRect(0, 0, width, height);
    if (savedImageData) {
      ctx.putImageData(savedImageData, dx * dpr, dy * dpr);
    }
    if (dragBounds) {
      const xr = dragBounds.xmax - dragBounds.xmin;
      const yr = dragBounds.ymax - dragBounds.ymin;
      // show coordinate under cursor
      const curX = dragBounds.xmin + (pos.x / width) * xr;
      const curY = dragBounds.ymin + (pos.y / height) * yr;
      coordsEl.textContent = `Cursor: ${curX.toFixed(6)}, ${curY.toFixed(6)}`;
    }
  }
```

Yes, `pos` is defined before `dragBounds` check, so it's in scope. Good.

Now let me also think about a potential issue: I should use the pos.x and pos.y directly (which are in CSS pixels / canvas space), not the `pos.x - rect.left` values... Actually, `getPos` returns `x = clientX - rect.left` and `y = clientY - rect.top`, which are canvas-relative CSS pixel coordinates. So pos.x ranges from 0 to width, and pos.y ranges from 0 to height. That's correct for computing the complex coordinate.

Let me reload and verify everything works.

Let me wait for the render to complete and then do a test interaction.

Render completed. Let me now do a drag test with a clear expected outcome.

The drag test shows:
- "Cursor: -0.791667, -0.145833" during the drag
- "Rendering…" means a new render was triggered

Let me calculate what the cursor position should be:
- Initial bounds: xmin=-2.25, xmax=1.25, ymin≈-1.166667, ymax≈1.166667
- Canvas dimensions: width=1200, height=800
- Drag from (400, 300) to (500, 350)
- Cursor at end: x=500, y=350

Cursor position in complex space:
cx = xmin + (x/width) * xr = -2.25 + (500/1200) * 3.5 = -2.25 + 1.458 = -0.792
cy = ymin + (y/height) * yr = -1.166667 + (350/800) * 2.333 = -1.166667 + 1.021 = -0.146

The displayed values (-0.791667, -0.145833) match! The cursor coord display is now correct.

After the drag (end at 500, 350, start at 400, 300):
dx = 500 - 400 = 100
dy = 350 - 300 = 50

New bounds:
xmin = dragBounds.xmin - (dx/width) * xr = -2.25 - (100/1200) * 3.5 = -2.25 - 0.292 = -2.542
xmax = dragBounds.xmax - (dx/width) * xr = 1.25 - 0.292 = 0.958

ymin = dragBounds.ymin - (dy/height) * yr = -1.166667 - (50/800) * 2.333 = -1.166667 - 0.146 = -1.313
ymax = dragBounds.ymax - (dy/height) * yr = 1.166667 - 0.146 = 1.021

New center: x=(-2.542+0.958)/2 = -0.792, y=(-1.313+1.021)/2 = -0.146

The center matches the cursor position from the drag! This is correct.

Now the view has shifted LEFT (xmin decreased) when dragging RIGHT (dx positive). This means the image followed the cursor (shifted right during drag, revealing content to the left, which means the view shifted left). This is the convention I chose.

Let me verify this works correctly. Now let me wait for the render to complete and try Reset.

Render completed. The coords still show "Cursor: -0.791667, -0.145833" from the drag. This is expected since the coord text is now set to the cursor position. After a reset, it should clear.

Let me test the Reset button by clicking on it.

The click at (20, 775) should be on the Reset button (which is at left:16px, bottom:16px). But the DOM still shows the old cursor coordinates. This might mean:
1. The click didn't hit the button (it hit the canvas instead, causing a drag with no movement)
2. The button click didn't fire

Wait, the button is positioned at `left:16px; bottom:16px`. The button text is "⟲ Reset view". The button is inside `#controls` which has no padding. So the button should be near (16, ~780) or so (16px from left, 16px from bottom). At (20, 775), this should be inside the button if the button is large enough.

But actually, looking at the result: the DOM still shows "Cursor: -0.791667, -0.145833". If the recalculate happened but the coords weren't cleared, that would be a bug. Let me check the resetView function again:

```javascript
function resetView() {
    if (isRendering) renderAborted = true;
    xmin = initialXmin;
    xmax = initialXmax;
    ymin = initialYmin;
    ymax = initialYmax;
    coordsEl.textContent = '';
    render();
}
```

This clears coords and starts a new render. After the render, the coords should be empty. But they show the old cursor values.

Wait, maybe the click at (20, 775) hit the canvas, not the button. Let me think about where the button actually is.

The controls div has `left:16px; bottom:16px`. The content of the button is "⟲ Reset view" which is maybe 100px wide and 30px tall. The button starts at (16, ~770) if the viewport is 800px tall (bottom = 800 - 16 = 784 for the div's bottom edge, button starts above that).

Actually, the `bottom:16px` means the controls div's bottom edge is 16px from the viewport bottom. So the bottom of the controls div is at y = 800 - 16 = 784. The button inside it starts somewhere above that. A click at (20, 775) might just hit the canvas right above the button.

Let me try clicking at (20, 782) which should be more in the button area.

Actually, it might also be that the click triggers a drag (which starts on the canvas) before the button can catch it. The canvas covers the full screen, so the click is on the canvas first. The canvas's mousedown handler calls `e.preventDefault()` which prevents the click from reaching the button.

Oh! That's the bug! The `onDragStart` handler on the canvas calls `e.preventDefault()`, and since the canvas covers the entire page (including the controls), any mousedown on the button area first hits the canvas, which prevents default, and the button never gets the click.

I need to allow the click to go through for the controls area. I can do this by:
1. Making the controls div have `pointer-events: auto` and the canvas have a lower z-index, or
2. Checking if the mousedown is over the controls area and skipping the drag

Actually, I already have `pointer-events:none` on the controls div and `pointer-events:auto` on the button. But the canvas has `pointer-events:auto` by default. So the canvas receives the mouse event first because it's "below" the control overlay in DOM order but still receives events.

Wait, actually the canvas is the first child of #container. The controls div is positioned absolutely over it. With pointer-events:none on the controls div and pointer-events:auto on the button, the button should receive events. But the canvas is below the controls div in z-order... or is it?

By default in HTML, elements that come later in DOM order are rendered on top. The canvas is before the controls div in the HTML, so the controls div is on top. With pointer-events:none on the controls div parent, events pass through to the canvas which is underneath. But the button has pointer-events:auto, so it should capture events that hit it.

Hmm, but the container has no z-index set, and both canvas and controls are in normal flow (canvas is block, controls is positioned). The canvas fills the container, and the controls are positioned absolutely over it. With pointer-events:none on the controls, events pass through to the canvas. With pointer-events:auto on the button, events on the button should be captured by the button.

Let me check if the issue is actually the z-ordering. The canvas fills the container. The controls div is absolutely positioned over the canvas. Since the controls div has pointer-events:none, clicks on it should pass through to the canvas underneath. But the button has pointer-events:auto, so clicks on the button should be captured by the button.

Actually, this should work correctly. The button with pointer-events:auto will capture events that are over it. The controls div with pointer-events:none passes events through to elements underneath... wait, that's not how it works.

pointer-events:none on a parent means the parent doesn't receive events, but its children with pointer-events:auto WILL receive events. So the button should work.

But wait: the canvas is BEHIND the controls div (z-order). The click first targets the controls div (which has pointer-events:none, so it doesn't capture the event). The event then goes through to the canvas underneath... but the canvas is behind the controls div, so the event doesn't reach it either. Actually, with pointer-events:none, the element and its children are transparent to events, but children with pointer-events:auto should still capture events.

I think there might be a subtlety. Let me try a different approach: I'll add a check in onDragStart to see if the click target is the button, and skip the drag if so.

Actually, looking more carefully at the event model: when you click on the button (which has pointer-events:auto), the event targets the button. But the mousedown event listener on the canvas would also fire because the event bubbles up to the canvas, right?

Wait, the events are on the canvas element and on the button element separately. When you click on the button:
1. mousedown fires on the button
2. The event bubbles up through the DOM tree
3. It does NOT reach the canvas because the canvas is NOT an ancestor of the button

The canvas and the button are siblings (both inside #container). Events on the button don't bubble to the canvas. So the canvas mousedown handler should NOT fire when clicking on the button.

But the DOM shows no change after the click. Let me check if maybe the click position (20, 775) is actually on the canvas, not the button.

Let me calculate: the viewport is 1200 × 800. The controls div is at left:16px, bottom:16px. The button is inside controls. The button has padding:6px 14px, font-size:13px. The button height would be about 13px + 12px padding = 25px. The bottom of the button is at y=800-16=784, and the top of the button is at y=784-25=759. So the button spans from approximately y=759 to y=784, and from x=16 to x=16+button_width.

The button text "⟲ Reset view" is about 10-11 characters at 13px font, so maybe ~80-90px wide. Plus 28px padding = ~108-118px. So from x=16 to x=~130.

The click at (20, 775) is within this rectangle (x: 16-130, y: 759-784). So it should have hit the button.

Hmm, but the result shows no rendering started ("Rendering…" is not shown), and the coords still show the old values. This suggests the click didn't trigger any action.

Maybe the issue is that the browser tool's click coordinates are relative to the viewport, but the button is positioned relative to its container which might have a different origin?

Let me just check if there's an issue with the code by reading the relevant parts again. Also, the "Rendering…" text is not shown, which means either:
1. The click didn't fire resetView (render wasn't called)
2. Or the render was very fast and already completed

Let me check again - actually, the DOM shows the coords are STILL "Cursor: -0.791667, -0.145833". If resetView had been called, `coordsEl.textContent = '';` would clear it. So it seems like resetView was NOT called.

Let me try a different approach: maybe I need to ensure the controls are above the canvas in z-order. Let me add a z-index to the controls div.

I'm running low on time. Let me reload the browser and quickly test the reset button, then finalize.

Actually, the main issue was probably that the click position wasn't quite right. Let me just reload and try a different click position for the reset button.

Let me wait for the render to complete.

Render completed. Let me try clicking on the reset button area. I'll try a broader click.

The DOM shows no change after the click. No "Rendering…" and no coord change. This suggests the button click didn't fire or it fired but the render didn't start.

Wait, actually if the click really triggered the reset and then render, we would see "Rendering…" briefly. But the DOM shows only "⟲ Reset view" without "Rendering…".

Let me check: after the reload, the render completed. Then I clicked at (50, 760). If this clicked on the canvas and triggered a drag (which is likely), then onDragStart would set isDragging=true and prevent default. On mouseup, onDragEnd would check dx,dy and if they're < 2, skip the render. So no "Rendering…" would appear.

But that means the button didn't get the click. Let me try to find where the button actually is by clicking more carefully.

Actually, the HTML structure is:
```html
<div id="container">
  <canvas id="canvas"></canvas>
  <div id="controls">
    <button id="resetBtn">⟲ Reset view</button>
    ...
  </div>
</div>
```

The controls div has `position:absolute; left:16px; bottom:16px; z-index:10; pointer-events:none;`. The button has `pointer-events:auto;`.

With the controls div having z-index:10, it's above the canvas (which has default z-index:auto, treated as 0). But pointer-events:none means events pass through the controls div to the canvas below. The button has pointer-events:auto, so events should be captured by the button.

Wait, but there's a subtlety: with `pointer-events:none` on the parent (controls div), events that hit the button area should... hmm, actually pointer-events:none on the parent means the parent itself doesn't capture events, but children with pointer-events:auto do capture them.

So when you click on the button area:
1. The browser determines which element is at that point
2. The controls div is at z-index:10, so it's considered first
3. Control div has pointer-events:none, so it's not the target
4. The button (child of controls) has pointer-events:auto, so it IS the target
5. The event fires on the button

This should work. But maybe there's an issue with my z-index. Let me check if the canvas has some z-index that interferes.

Actually, I think the issue might be that the button's position isn't where I think it is. The controls div has `left:16px; bottom:16px`. The button is inside it. With `flex-direction:column; gap:6px`, the button is at the top of the controls div. The controls div's bottom is at y=800-16=784, and since there's no explicit height, it sizes to its content. With the button (~25px tall), status (~18px), and coords (~18px), plus gaps, the controls div is about 67px tall. Its top is at y=784-67=717.

So the button is at approximately y=717 to y=742 (top 25px of the controls div). At x=16 to x=~130.

The click at (50, 760) would be below the button area (760 > 742), so it would hit the status/coords area which are part of the controls div. With pointer-events:none on controls, and those spans not having pointer-events:auto, the click passes through to the canvas underneath.

I need to click higher up. Let me try (50, 725).

But actually, I'm spending too much time on this. Let me just make the flag that the reset button is definitely clickable by making it more prominent or using a different approach. Let me add keyboard shortcut 'r' which should work regardless of the button position.

Actually, looking at my code, I already have the keyboard shortcut:
```javascript
document.addEventListener('keydown', function(e) {
    if (e.key === 'r' || e.key === 'R') resetView();
});
```

But the browser tool might not support keyboard input easily. Let me try a key action.

The keyboard shortcut 'r' worked! It triggered resetView which called `coordsEl.textContent = '';` and then `render()` which shows "Rendering…". 

Now the code is working correctly. Let me wait for the render to complete and then do one final check - test zoom on a known point.

Actually, I realize I can't verify the zoom position visually since images aren't supported. But the code logic is correct - the wheel event uses clientX/clientY to determine the zoom center.

Let me do a final verification: try a zoom event and see if the coords update correctly.

But first, let me make sure the initial render completes.

Good, render completed. Now let me try the keyboard shortcut for zoom is not available, but I can try to scroll. Let me also check that the zoom centered on the cursor works correctly.

Since the browser tool's scroll action might not support custom position, let me just check if scroll zoom causes a re-render with updated coords.

Let me try to click first at a specific position, then scroll. But the scroll action uses its own position.

Actually, let me just scroll and check the coords. If the scroll fires at (0,0) (top-left), the coords should show the top-left complex coordinate.

Initial bounds: xmin=-2.25, xmax=1.25, ymin=-1.166667, ymax=1.166667.

After zoom at (0, 0) with factor 1/1.12 ≈ 0.8929:
cx = -2.25 + 0/1200 * 3.5 = -2.25
cy = -1.166667 + 0/800 * 2.333 = -1.166667

nxr = 3.5 * 0.8929 = 3.125
nyr = 2.333 * 0.8929 = 2.083

new xmin = -2.25 - 3.125/2 = -3.8125
new xmax = -2.25 + 3.125/2 = -0.6875
new ymin = -1.166667 - 2.083/2 = -2.208333
new ymax = -1.166667 + 2.083/2 = -0.125

The coords should show "Center: -2.250000, -1.166667" (the cursor position at top-left).

Let me try scroll and check.

Hmm, the "Rendering…" text isn't showing. The coords also aren't showing. Maybe the scroll event isn't reaching the canvas.

Wait, maybe the scroll event handler needs the canvas to be focused, or maybe the browser tool sends the scroll to the page as a whole rather than targeting the canvas.

Let me check: I attached the wheel event listener to the canvas specifically:
```javascript
canvas.addEventListener('wheel', onWheel, { passive: false });
```

The scroll action might be scrolling the page instead of sending a wheel event to the canvas. But I have `overflow:hidden` on the body, which prevents page scrolling. And the wheel handler calls `e.preventDefault()`, which also prevents page scrolling.

But if the scroll event is sent to the page/document level rather than to the canvas element, it might not trigger the canvas's wheel handler.

Let me try attaching the wheel handler to the document as well. Actually, I should attach it to the wheel on the container or document to ensure it catches all wheel events.

Let me change the wheel listener to target the document/window instead.

Actually, the scroll event might also be at the page level. Let me add a document-level listener as well.

Wait, this will cause double-processing of wheel events - once for the canvas listener and once for the document listener. The canvas listener will handle events that target the canvas, and the document listener will also handle those (since events bubble up). But the document listener will ALSO handle events that don't target the canvas.

This could cause issues: when scrolling on the canvas, two renders would be triggered.

Let me fix this by removing the canvas listener and only using the document listener. That way all wheel events in the page get handled once.

Good. Now wheel events anywhere on the window will be caught and handled, and `e.preventDefault()` will prevent page scrolling. Let me reload and test scroll again.

Let me wait for the render to complete and then test scroll.

Now let me test the scroll. The scroll action with delta=-200 (negative = zoom in).

Scroll zoom works now! The coords show "Center: -2.250000, -1.166667" which corresponds to the top-left corner of the initial viewport (the scroll position was at the top-left, which is the default in this browser tool). This means:

- cx = -2.25 (the left edge, where the scroll event fired)
- cy = -1.166667 (the top edge)

After zoom, the center shifted to these values. This is correct behavior for zoom centered on the top-left corner.

Let me now test reset via keyboard to return to the initial view.

Reset with 'r' key works. It shows "Rendering…" which means it started a fresh render. The coords were cleared (no coords shown in the DOM). Let me wait for completion.

Reset completed successfully. The view is back to the initial state with no coordinates displayed. The key behaviors are verified:

1. ✅ Initial render of the Mandelbrot set with smooth escape-time coloring
2. ✅ Chunked rendering (64-row strips) keeps UI responsive during computation
3. ✅ Drag to pan with visual feedback during drag (saved image data shown at offset)
4. ✅ Wheel zoom centered on cursor (coords show correct cursor position)
5. ✅ Reset view via keyboard 'r' (clears coords and re-renders initial view)
6. ✅ Prevent wheel from scrolling the page (e.preventDefault() + overflow:hidden)
7. ✅ Adaptive iterations based on zoom level

However, there's one issue I need to fix: the click on the Reset button (via mouse) doesn't seem to work because the canvas's mousedown handler captures events before they reach the button. The keyboard shortcut works, but the button should also work.

Let me fix this by checking if the event target is not the canvas (i.e., it's a control button) in the drag start handler.

Actually wait - events on the button shouldn't trigger the canvas's mousedown handler at all, because the button is not a child of the canvas. They're siblings. Events on the button bubble up through #container, not through the canvas.

But the canvas covers the full viewport. The controls div with z-index:10 and pointer-events:none should let events pass through to the canvas for areas not covered by the button. But the button has pointer-events:auto, so events on the button should target the button.

The issue was that my click position (50, 760) might not have been inside the button's rectangle. Let me try to fix this by ensuring the button is definitely clickable with a broader clickable area.

Actually, let me just make sure the keyboard shortcut works (it does) and move on. The button click issue is likely just a coordinate mismatch with the browser tool.

Let me also quickly verify that the file is complete and save it. Then I'll report what I verified.

Actually, I should also read the final file to make sure everything is consistent.

The code looks complete. Let me do a final check - I need to make sure the button can actually be clicked. The issue I noticed earlier was the click on the button didn't seem to work. This might be because:

1. The `canvas` has `mousedown` handler that calls `e.preventDefault()`.
2. The canvas fills the entire page.
3. The controls div has `z-index:10` and `pointer-events:none`, but the button has `pointer-events:auto`.

When a mouse event fires on the button:
- Since the button has `pointer-events:auto`, the button is the event target
- The event does NOT reach the canvas (the canvas is not an ancestor of the button)
- So the canvas's mousedown handler should NOT fire

But wait, I have `mousedown` on `canvas` (not `window`). Events on the button don't bubble to the canvas. So this should work.

The problem might just be the browser tool's click coordinates. Let me try a different approach to verify - maybe I should just ensure the file is saved and proceed.

Actually, I realize I might have another issue. The `resetBtn.addEventListener('click', resetView)` binds to the click event. But the button has `pointer-events:auto` which should make it clickable. In my test earlier, the click at (40, 760) might have missed the button.

Let me fix this by making the button more prominent - adding some padding or making it bigger. But actually, the issue might be that in the sandboxed iframe, the z-index or pointer-events work differently.

Let me try one more click at a higher position to hit the button. But I'm running out of time. Let me just ensure the file is complete and saved.

Actually, one more thing I want to fix: I notice that the `onWheel` handler checks `if (mx < 0 || mx > width || my < 0 || my > height) return;`. But since I changed the listener to `window.addEventListener('wheel', ...)`, the `e.clientX` and `e.clientY` could be anywhere on the page. The check ensures we only process wheel events that are within the canvas. That's good - wheel events outside the canvas area (e.g., on the controls) will be ignored but still prevented from scrolling the page. That's correct behavior.

Let me also verify: the `getPos` function in `onDragStart` uses `e.clientX` and subtracts `rect.left`. For a mousedown on the canvas, this should be correct.

I think the implementation is complete. Let me save the final file.

Actually, wait - I just realized there might be a subtle issue with the drag offset during drag. When I use `putImageData(savedImageData, dx * dpr, dy * dpr)`, I'm putting the saved image data at position (dx*dpr, dy*dpr) in the canvas backing store (since `putImageData` ignores the transform). The saved image has dimensions pw × ph (device pixels). 

If dx = 100 (CSS pixels), and dpr = 2, then `dx * dpr = 200`. The image data is placed at device pixel (200, 200*dpr). So the image shifts right by 200 device pixels, which is 100 CSS pixels. That's correct!

But there's another issue: `putImageData` places the image data at the specified position, overwriting pixels. Since the saved image has the full backing store size, placing it at (dx*dpr, dy*dpr) will clip it at the edges. If the offset is positive, the image moves right and down, showing empty space on the top-left. This is the correct visual feedback for dragging right and down.

OK this is all correct.

The file is complete. Let me finalize.

The file loads correctly. No JavaScript errors. "Rendering…" shows that the app started the computation. Let me wait for completion and then report.

The file is saved at `/tmp/job-U6bci4/index.html`. Let me verify.

The file is saved (11855 bytes, 402 lines). Let me provide a quick summary of what was verified.

Let me also check one more thing - the browser tool's inspect often shows the DOM state from the time of the last action, which is BEFORE a pending render would have had time to complete. So the "Rendering…" text in the DOM just means the render hasn't completed yet at the time the DOM snapshot was taken. The final state (with empty status) shows the render completed successfully.

I've verified:
1. ✅ Page loads without JavaScript errors
2. ✅ Initial render starts and completes (status goes from "Rendering…" to empty)
3. ✅ Drag panning with visual feedback (coords update during drag, re-render on release)
4. ✅ Wheel zoom triggers re-render with updated coordinates
5. ✅ Reset via keyboard 'r' clears coordinates and re-renders initial view
6. ✅ Adaptive iterations (calcMaxIter function)
7. ✅ Smooth escape-time coloring algorithm
8. ✅ Chunked rendering for responsiveness

Unverified:
- The Reset button click (may be a browser-tool coordinate issue, keyboard shortcut works)
- Visual appearance of the fractal (no images in this environment)
- Zoom staying under cursor (scroll position can't be controlled in the tool)
- Window resize behavior