Mandelbrot explorer · solar-pro4

The user wants me to build an interactive Mandelbrot set explorer. Let me create a comprehensive single-page web app with:

1. Full-screen canvas
2. Mandelbrot set computation with smooth escape-time coloring
3. Initial view showing the main cardioid and surrounding lobes
4. Drag to pan
5. Mouse-wheel zoom centered on cursor position
6. Dynamic iteration count that increases with zoom
7. Reset view button
8. Prevent default wheel scrolling

Let me think about the implementation:

**Initial bounds**: The Mandelbrot set spans roughly from -2 to 1 on the real axis and -1.5 to 1.5 on the imaginary axis. The main cardioid is centered around 0.

**Color scheme**: I'll use a smooth gradient based on the escape time. For points inside the set (never escape), use a distinct color (like black). For outside points, use a smooth coloring algorithm based on the number of iterations and the magnitude of the final iteration.

The smooth coloring can be done using:
- `n + 1 - log(log(|z|)) / log(2)` as the smooth iteration count
- Then map this to a color gradient using sine-based color cycling or HSV

Let me use a HSV-based approach or a smooth gradient with sine waves for colorful, psychedelic effect.

**Iterations**: Start with something like 100-200 iterations, and increase as we zoom in. A common heuristic is to multiply iterations by roughly the zoom factor or use `iterations = baseIterations * (1 + log2(zoom))`.

**Performance**: For a full-screen canvas, we need efficient pixel-by-pixel computation. I'll use ImageData and putImageData.

Let me think about the geometry:
- Canvas dimensions: let's say the window size
- The Mandelbrot set extends from approximately (-2, -1.5) to (1, 1.5) in the complex plane

For the initial view, I want to show the "complete main cardioid and surrounding lobes". The main cardioid extends from about -0.75 to 0.25 on the real axis, and -0.65 to 0.65 on the imaginary axis. To show the full set including the cardioid and the surrounding bulbs, I should probably start with bounds that show the classic view: real from -2 to 1, imaginary from -1.5 to 1.5.

Actually, let me think more carefully. The user says "Initially show the complete main cardioid and surrounding lobes." This suggests a zoomed-in view that shows the cardioid and its surroundings more clearly, rather than the full set. But the user also says "Reset view to restore the initial bounds" which suggests these initial bounds should be user-facing. Let me go with the classic full-set view first, which shows the entire set including the cardioid and lobes.

Wait, re-reading: "Initially show the complete main cardioid and surrounding lobes." This could mean the classic view that shows the entire Mandelbrot set. The "main cardioid and surrounding lobes" are the main features visible in the classic view.

Let me go with the classic view: bounds of [-2, 1] for real and [-1.5, 1.5] for imaginary, which shows the entire set.

Actually, for a nicer initial view that highlights the cardioid, I could use bounds that focus more on the cardioid area, but still show surrounding features. The classic view from -2 to 1 (real) and -1.5 to 1.5 (imaginary) shows the whole set including the cardioid and all the bulbs.

Let me go with that.

Now for the implementation:

```javascript
// Mandelbrot iteration
function mandelbrot(cx, cy, maxIter) {
    let x = 0, y = 0;
    let x2 = 0, y2 = 0;
    let iter = 0;
    while (x2 + y2 <= 4 && iter < maxIter) {
        y = 2 * x * y + cy;
        x = x2 - y2 + cx;
        x2 = x * x;
        y2 = y * y;
        iter++;
    }
    if (iter === maxIter) return -1; // inside set
    // smooth iteration count
    const log2 = Math.log(2);
    const logLog = Math.log(Math.log(x2 + y2) / 2) / log2;
    const smooth = iter + 1 - logLog;
    return smooth;
}
```

For coloring, I'll use a smooth gradient. A popular approach is:

```javascript
function getColor(smoothIter, maxIter) {
    if (smoothIter < 0) return [0, 0, 0]; // inside set - black
    
    // Normalize
    const t = smoothIter / maxIter;
    
    // Use sine waves for colorful gradient
    const r = Math.sin(2 * Math.PI * t * 0.8 + 0) * 127 + 128;
    const g = Math.sin(2 * Math.PI * t * 0.8 + 2) * 127 + 128;
    const b = Math.sin(2 * Math.PI * t * 0.8 + 4) * 127 + 128;
    
    return [r, g, b];
}
```

This gives a nice psychedelic effect. Or I could use a more controlled palette.

Let me think about making a really nice visual. I'll use a combination approach - base it on the smooth iteration count with some color cycling.

Actually, for a really nice Mandelbrot render, I'll do:
1. Black for inside points
2. Smooth color mapping for outside points using a rich gradient

For the gradient, I'll use a palette function that maps [0, 1] to RGB:

```javascript
function palette(t) {
    // A multi-stop gradient
    // This could use various approaches
}
```

Let me think about a nicer palette. I could use:
- A "fire" palette (dark red → bright yellow → white)
- A "rainbow" palette
- A custom gradient with multiple stops

I'll go with something visually appealing - maybe a blue/purple/magenta/fire gradient or a nice hue-cycling gradient.

For performance, especially on full-screen, I should:
1. Use requestAnimationFrame
2. Maybe compute at a lower resolution and scale up, or use a progressive render approach
3. Use typed arrays for pixel data

Actually, let me think about the resolution. On a 1920x1080 display, that's ~2 million pixels. Computing Mandelbrot for each pixel with 100-1000 iterations could be slow. But modern JS engines with typed arrays can handle this reasonably well.

For responsiveness, I'll render in chunks or use a lower resolution during interaction and then refine. Or I could use OffscreenCanvas with a web worker... but that adds complexity.

Let me keep it simpler - compute the full image but show a loading indicator. For a 1080p canvas with 200 iterations, this should take maybe 1-3 seconds in modern JS, which is acceptable.

I can also use the trick of computing at half resolution during pan/zoom and then doing a full resolution render after the interaction ends.

Let me implement this properly:

1. During active pan/zoom (mouse drag or wheel), render at reduced resolution
2. After interaction ends, render full resolution
3. Use requestAnimationFrame and show progress

Actually, let me keep it even simpler and just do full renders but make sure to cancel previous renders if a new one starts. The user wants "controls responsive during rendering" - so I should render incrementally or in a way that doesn't block the UI.

A good approach:
1. Use a flag `isRendering` 
2. Render in chunks using setTimeout to yield to the UI
3. Or use requestIdleCallback... 

Actually, for a canvas rendering, the simplest approach that keeps things responsive is to use `setTimeout`/`requestAnimationFrame` to break up the work. But for Mandelbrot, each pixel is independent, so we can easily split the work.

Let me implement a chunked renderer:

```javascript
function render() {
    const imageData = ctx.createImageData(width, height);
    const data = imageData.data;
    const totalPixels = width * height;
    const chunkSize = 5000; // pixels per chunk
    let currentPixel = 0;
    
    function renderChunk() {
        const end = Math.min(currentPixel + chunkSize, totalPixels);
        for (let i = currentPixel; i < end; i++) {
            const px = i % width;
            const py = Math.floor(i / width);
            // compute color
            const idx = i * 4;
            data[idx] = r;
            data[idx+1] = g;
            data[idx+2] = b;
            data[idx+3] = 255;
        }
        currentPixel = end;
        ctx.putImageData(imageData, 0, 0);
        if (currentPixel < totalPixels) {
            requestAnimationFrame(renderChunk);
        }
    }
    renderChunk();
}
```

Wait, but putImageData each chunk would be inefficient because it copies the entire image data each time. Better to accumulate and only call putImageData once at the end, or use a smaller canvas for the chunks.

Actually, a better approach: compute the entire ImageData and then put it once. But that blocks the main thread. For responsiveness, I can:
1. Use a web worker (complex but best)
2. Use progressive rendering with smaller canvases
3. Just accept the block and show a "computing..." indicator

Let me go with a hybrid: render at full resolution but show a "computing" overlay. For most modern hardware, a 1080p Mandelbrot render with adaptive iterations should take 1-2 seconds, which is acceptable.

But actually, I can do even better. Let me compute in chunks and putImageData each chunk. To avoid the overhead of copying the full ImageData each time, I can use a different approach:

1. Create the full ImageData
2. Fill it in chunks
3. Call putImageData only once at the end

But during the fill, the canvas won't show progress. To show progress, I can put a semi-transparent overlay or just show a "computing" text.

For a really nice implementation, let me do the chunked approach but only putImageData once. I'll show a loading indicator.

Let me also consider: for the wheel zoom centered on the cursor, I need to:
1. Get the mouse position relative to the canvas
2. Convert to complex coordinates
3. Zoom in/out by a factor (e.g., 1.1 or 1.2) centered on that point
4. Recompute

For panning:
1. Track mouse down, move, up
2. On mouse move during drag, shift the bounds by the pixel delta converted to complex coordinates
3. Recompute (or during drag, just shift without recompute? No, recompute is needed since we're showing different parts)

Actually for panning during drag, I could either recompute on each move (expensive) or just shift the existing rendered image and recompute after the drag ends. The latter is more performant but doesn't show new detail during drag. The former shows new detail but could be slow.

Since the user says "Drag pans the image with the pointer" and "Recompute the fractal after navigation rather than scaling a static image", I think recomputing after navigation (after the drag ends) is acceptable. During the drag, I can either show the shifted image or just wait until the drag ends.

Actually, re-reading: "Recompute the fractal after navigation rather than scaling a static image." This means: don't just scale/translate the existing image; recompute the fractal for the new view. So during drag, I should probably recompute (or at least after the drag ends). Let me recompute after the drag ends, and during the drag, maybe just shift the view (which is essentially panning without recompute - not ideal but performant).

Hmm, but the user also says "Use sufficient iterations to reveal new detail as the user zooms, and keep controls responsive during rendering." This suggests that rendering should be responsive during interaction.

Let me implement it as:
1. During drag: update the view bounds, start a render at reduced resolution (or just start the full render and let it run)
2. During wheel: update bounds, start render
3. After interaction completes: if still rendering, let it finish; the result will be the new view

Actually, I think the cleanest approach is:
1. When navigation starts (drag start or wheel), cancel any ongoing render
2. Update the view bounds
3. Start a new render
4. During the render, show the canvas progressively updating
5. When navigation ends, let the render complete naturally

For progressive rendering during drag, I can render at a reduced resolution and then refine. But that adds complexity. Let me keep it simpler: just render the full image, and show a "computing" indicator. The render should be fast enough on modern hardware.

Let me also think about the iteration count. Initially, with bounds of [-2, 1] × [-1.5, 1.5], I'll use something like 100-200 iterations. As the user zooms in, I'll increase the iterations. A reasonable formula:

```
maxIter = baseIter + Math.floor(Math.log2(zoomFactor) * iterPerDoubling)
```

Where `zoomFactor` is how much we've zoomed in from the initial view, `baseIter` is the initial iteration count (e.g., 100), and `iterPerDoubling` is how many extra iterations per doubling of zoom (e.g., 50-100).

Actually, let me use a simpler approach: track the zoom level and compute iterations accordingly.

Let me now write the code. I'll make it a nice, polished single-page app.

Here's my plan for the HTML file:

```html
<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Mandelbrot Explorer</title>
  <style>
    /* Full screen, dark theme, controls overlay */

  </style>
</head>
<body>
  <canvas id="canvas"></canvas>
  <div id="controls">
    <button id="resetBtn">Reset view</button>
    <span id="info">Drag to pan · Scroll to zoom</span>
  </div>
  <div id="loading">Computing...</div>
  <script>
    // Full implementation
  </script>
</body>
</html>
```

Let me now write the full code. I'll focus on:
1. Clean, attractive UI
2. Correct Mandelbrot computation
3. Smooth coloring
4. Responsive interaction
5. Good performance

Let me code it up.

For the color scheme, I want something really beautiful. Let me use a multi-stop gradient:

I'll use a palette function based on the smooth iteration value. One approach that looks great:

```javascript
function hslToRgb(h, s, l) {
    // HSL to RGB conversion
}
```

Or I can use a direct palette with sine-based coloring which creates beautiful psychedelic effects:

```javascript
function palette(t) {
    // t in [0, 1)
    const r = Math.sin(2 * Math.PI * t * 2.0) * 0.5 + 0.5;
    const g = Math.sin(2 * Math.PI * t * 2.0 + 2.094) * 0.5 + 0.5; // + 120°
    const b = Math.sin(2 * Math.PI * t * 2.0 + 4.189) * 0.5 + 0.5; // + 240°
    return [r * 255, g * 255, b * 255];
}
```

This creates a smooth rainbow-like gradient. For a more "fire" or "ocean" look, I can use different color mappings.

Actually, let me create a more sophisticated palette with multiple color stops. I'll define a gradient with several stops and interpolate:

```javascript
const paletteStops = [
    { pos: 0.0, r: 0, g: 0, b: 0 },
    { pos: 0.1, r: 0, g: 0, b: 128 },
    { pos: 0.3, r: 0, g: 128, b: 255 },
    { pos: 0.5, r: 128, g: 0, b: 255 },
    { pos: 0.7, r: 255, g: 0, b: 128 },
    { pos: 0.9, r: 255, g: 200, b: 0 },
    { pos: 1.0, r: 255, g: 255, b: 255 },
];
```

Hmm, let me think about what looks best for Mandelbrot. Popular choices:
1. **Black inside, colorful outside** (the classic approach) - I'll do this
2. **Smooth gradient** based on escape time

For the outside colors, I'll use a beautiful gradient. Let me try something like a "neon" or "cosmic" palette.

I think a good approach is to use a palette based on the smooth iteration value, mapped through a color function. Let me use HSL with hue cycling, which gives beautiful results:

```javascript
function getColor(t, maxIter) {
    if (t < 0) return [0, 0, 0]; // inside
    
    // Normalize t to [0, 1)
    t = (t % 1); // or use t / maxIter
    
    // Use HSL with hue = t * 360
    const hue = t * 360;
    const saturation = 80;
    const lightness = 50 + 30 * (1 - t);
    
    // Convert HSL to RGB
    // ...
}
```

Actually, for really smooth coloring, I should use the fractional iteration count directly. Let me use:

```javascript
// smooth iteration
const smoothIter = iter + 1 - Math.log(Math.log(zMag)) / Math.log(2);

// Normalize
const t = smoothIter / maxIter;

// Map to color
// I'll use a beautiful palette
```

OK, let me just write the code now. I'll make a nice palette and be done with it.

Let me think about the structure:

1. Canvas setup - full window, handle resize
2. View state - xMin, xMax, yMin, yMax (or center + zoom)
3. Rendering - compute Mandelbrot, apply color, draw
4. Interaction - mouse drag, wheel zoom
5. UI - reset button, info display

For the view state, I'll use:
- `centerX, centerY` - center of the view in complex coordinates
- `zoom` - zoom level (pixels per unit in complex space)
- Or equivalently: xMin, xMax, yMin, yMax

I think center + zoom is cleaner for zoom operations.

Initial state:
- centerX = -0.5 (center of the main cardioid area)
- centerY = 0
- zoom = canvasWidth / 3 (so the view spans from -2 to 1 approximately)

Wait, let me calculate: if canvasWidth is W, and zoom is pixels per unit, then the width in complex units is W/zoom. If I want the initial view to span from -2 to 1 (width 3), then zoom = W/3.

For a 1920px wide canvas, zoom = 640. So each pixel is 1/640 of a complex unit.

For wheel zoom centered on cursor:
1. Get cursor position in complex coords: cx = xMin + (mouseX / canvasWidth) * (xMax - xMin)
2. Zoom factor (e.g., 1.1 for zoom in)
3. New bounds: centered on cx. New xMin = cx - (cx - xMin) / factor, new xMax = cx + (xMax - cx) / factor

This keeps the point under the cursor fixed.

Let me implement this with center + zoom:
- cx, cy: center in complex coords
- zoom: pixels per unit

To zoom centered on cursor at pixel (mx, my):
1. Convert pixel to complex: 
   - complexX = cx - (canvasWidth/2 - mx) / zoom
   - complexY = cy - (canvasHeight/2 - my) / zoom
   (or equivalently: complexX = cx + (mx - canvasWidth/2) / zoom)
2. Apply zoom factor f:
   - zoom *= f
3. Adjust center so the point stays fixed:
   - cx = complexX - (mx - canvasWidth/2) / zoom (after zoom)
   - cy = complexY - (my - canvasHeight/2) / zoom (after zoom)

Wait, let me think again. If I zoom in by factor f (f > 1 for zoom in):
- New zoom = old zoom * f
- The point that was at pixel (mx, my) should still be at (mx, my) after zoom
- Before zoom: complexX = cx + (mx - canvasWidth/2) / oldZoom
- After zoom: we want complexX = newCx + (mx - canvasWidth/2) / newZoom
- So: newCx = complexX - (mx - canvasWidth/2) / newZoom

This is correct.

OK let me write the code. I'll also add a nice info display showing the current zoom level and center coordinates.

For performance, I'll render at full resolution but use a "rendering..." indicator. Let me also add the ability to render at reduced resolution during active interaction and then upgrade to full resolution.

Actually, let me implement a two-phase render:
1. Quick render at half resolution during interaction (updates every ~100ms or on each move)
2. Full resolution render after interaction ends

But this adds complexity. Let me keep it simpler: just render full resolution, and if a new interaction starts while rendering, cancel the previous render and start a new one. Show a "computing" indicator.

Actually, I realize that for a truly responsive experience, I should render progressively. Let me use a chunked approach where I render rows of the image one at a time, updating the canvas after each row. This way the user sees the image building up.

But putImageData doesn't work well for partial updates since it replaces the entire canvas. I could use a separate canvas for the render and then composite it, or use fillRect for each pixel (too slow), or use an ImageData and only put it once at the end.

Alternative: Use two canvases - one for the current render and one for display. Render to the offscreen canvas and when done, copy to the display canvas. This doesn't help with progressive updates though.

For progressive updates with ImageData:
1. Create ImageData
2. Fill it row by row
3. After each row, call putImageData - but this replaces the whole canvas with the partial data

Actually, putImageData does copy the entire ImageData to the canvas. So if I put partial data, I'll see a partially filled image. But putImageData is a copy operation, so doing it many times could be slow.

Let me try a different approach: render to an offscreen canvas using fillRect for each pixel, but in chunks. No, fillRect is too slow for millions of pixels.

OK, the best approach for progressive rendering with Canvas 2D:
1. Use typed arrays and manual pixel manipulation
2. Render in chunks
3. Put the ImageData once at the end

For showing progress, I'll put a semi-transparent "computing" overlay or just show a status text.

Let me go with: render in chunks using requestAnimationFrame, fill the ImageData, and put it once at the end. Show a "computing..." indicator during rendering. This keeps the UI responsive (the chunks yield to the browser) and shows the final result cleanly.

Actually wait - I should putImageData more frequently to show progress. Let me put after each chunk. Since putImageData copies the data, and my chunks are filling the same buffer, I need to be careful. Let me just put the ImageData at the end, and show a loading spinner/text.

Hmm, let me reconsider. Here's a cleaner approach:

1. On navigation, set `isRendering = true`
2. Start a render loop using requestAnimationFrame
3. Each frame, compute a chunk of pixels and put the updated ImageData
4. Wait, putImageData with partial data will show a partially rendered image but will clip... no, putImageData puts the entire image data to the canvas, replacing what's there. So if I have a partially filled ImageData, I'll see a partially filled image.

OK so the approach is:
1. Create ImageData(width, height)
2. Initialize all pixels to black (or some default)
3. Each render chunk: fill a portion of the pixels, then putImageData
4. The canvas shows the progressive render

This works! The putImageData call with partially filled data will show the image being built up. The overhead of putImageData is acceptable if we do it every N pixels.

Let me implement this. I'll use a chunk size of maybe 20000 pixels (about 20 rows for a 1080p image) and putImageData after each chunk.

Actually, for 1080p (1920x1080 = 2,073,600 pixels), computing each pixel with ~100-500 iterations could take some time. Let me estimate: if each pixel takes ~1μs (which is optimistic for complex arithmetic), total time is ~2 seconds. With chunked rendering yielding to the browser, it might be more like 3-5 seconds.

For a smoother experience, I could:
1. Render at 1/2 resolution initially (1/4 the pixels)
2. Then render the full resolution

Or simply use a lower iteration count during interaction and increase it after.

Let me implement a simple approach:
- Track `isActive` (whether user is interacting)
- During active interaction, use fewer iterations and render at half resolution
- When interaction stops, render at full resolution with full iterations
- The transition should be smooth

Actually, this is getting complex. Let me simplify:

1. Always render at full resolution
2. Use adaptive iterations based on zoom level
3. During rendering, show a "computing" overlay
4. Accept that rendering takes 1-3 seconds
5. Cancel previous render if a new navigation starts

This is the simplest approach that meets the requirements. Let me go with this.

Wait, the requirement says "keep controls responsive during rendering." This means the UI shouldn't freeze during rendering. With my chunked approach using requestAnimationFrame, the UI stays responsive because each chunk yields control back to the browser. So this requirement is met.

OK, let me write the code now.

Here's my implementation plan:

```javascript
const canvas = document.getElementById('canvas');
const ctx = canvas.getContext('2d');

let view = {
    cx: -0.5,    // center x in complex plane
    cy: 0,       // center y
    zoom: 1      // zoom level (pixels per unit, relative to base)
};

const BASE_ZOOM = 3; // initial zoom: canvasWidth / 3 gives view from -2 to 1

let isRendering = false;
let renderRequested = false;
let lastRenderTime = 0;

function resize() {
    canvas.width = window.innerWidth;
    canvas.height = window.innerHeight;
    // Adjust zoom to maintain the same view
    view.zoom = canvas.width / BASE_ZOOM;
    render();
}

function render() {
    if (isRendering) return;
    isRendering = true;
    renderRequested = false;
    
    const width = canvas.width;
    const height = canvas.height;
    const imageData = ctx.createImageData(width, height);
    const data = imageData.data;
    
    const xMin = view.cx - width / (2 * view.zoom);
    const xMax = view.cx + width / (2 * view.zoom);
    const yMin = view.cy - height / (2 * view.zoom);
    const yMax = view.cy + height / (2 * view.zoom);
    
    // Compute iterations based on zoom
    const zoomRatio = view.zoom / (canvas.width / BASE_ZOOM);
    const maxIter = Math.floor(100 + Math.log2(zoomRatio + 1) * 80);
    const maxIterClamped = Math.min(maxIter, 2000); // cap
    
    let completedPixels = 0;
    const totalPixels = width * height;
    
    function processChunk() {
        const chunkSize = 10000;
        const start = completedPixels;
        const end = Math.min(start + chunkSize, totalPixels);
        
        for (let i = start; i < end; i++) {
            const px = i % width;
            const py = Math.floor(i / width);
            
            const cx = xMin + (px / width) * (xMax - xMin);
            const cy = yMin + (py / height) * (yMax - yMin);
            
            const iter = mandelbrot(cx, cy, maxIterClamped);
            const color = getColor(iter, maxIterClamped);
            
            const idx = i * 4;
            data[idx] = color[0];
            data[idx + 1] = color[1];
            data[idx + 2] = color[2];
            data[idx + 3] = 255;
        }
        
        completedPixels = end;
        ctx.putImageData(imageData, 0, 0);
        
        if (completedPixels < totalPixels) {
            requestAnimationFrame(processChunk);
        } else {
            isRendering = false;
            document.getElementById('loading').style.display = 'none';
        }
    }
    
    document.getElementById('loading').style.display = 'flex';
    requestAnimationFrame(processChunk);
}

function mandelbrot(cx, cy, maxIter) {
    let x = 0, y = 0;
    let iter = 0;
    while (x * x + y * y <= 4 && iter < maxIter) {
        const xtemp = x * x - y * y + cx;
        y = 2 * x * y + cy;
        x = xtemp;
        iter++;
    }
    if (iter === maxIter) return -1;
    
    // Smooth coloring
    const logZn = Math.log(x * x + y * y) / 2;
    const smooth = iter + 1 - Math.log(logZn) / Math.log(2);
    return smooth;
}

function getColor(smoothIter, maxIter) {
    if (smoothIter < 0) return [0, 0, 0]; // inside set - black
    
    // Normalize to [0, 1)
    const t = (smoothIter % 1); // fractional part for smooth coloring
    
    // Use a rich color palette
    // I'll use a multi-stop gradient or sine-based coloring
    
    // Let's use a really nice palette
    const r = Math.sin(2 * Math.PI * t * 3.0 + 0.0) * 127 + 128;
    const g = Math.sin(2 * Math.PI * t * 3.0 + 2.094) * 127 + 128;
    const b = Math.sin(2 * Math.PI * t * 3.0 + 4.189) * 127 + 128;
    
    // Add some variation based on iteration count for more depth
    const intensity = Math.min(1, smoothIter / maxIter * 2);
    
    return [
        Math.floor(r * intensity),
        Math.floor(g * intensity),
        Math.floor(b * intensity)
    ];
}
```

Hmm wait, I want the inside of the set to be a distinct color. I'll use black for inside, and the colorful gradient for outside. That's the classic approach.

But some people prefer a non-black color for inside. Let me use a very dark blue or dark color for inside, to distinguish it from the outside while still being clearly "inside."

Actually, the user said "with a distinct color for points treated as inside the set." Black is distinct, but let me use a dark blue or dark purple for a nicer look. Or I could use black and it's fine - black is distinct from the colorful exterior.

Let me use black for inside. It's classic and clearly distinct.

Now for the palette, let me make it really beautiful. I'll use a palette based on the smooth iteration with multiple color stops.

Let me define a nice palette:

```javascript
// A beautiful palette for Mandelbrot
// Using HSV-like coloring with hue cycling
function getColor(smoothIter, maxIter) {
    if (smoothIter < 0) return [0, 0, 0];
    
    // Use the fractional part for smooth coloring
    const frac = smoothIter - Math.floor(smoothIter);
    
    // Map to a beautiful gradient
    // I'll use multiple sine waves for a rich palette
    const r = Math.sin(2 * Math.PI * frac * 2.5 + 0.0) * 0.5 + 0.5;
    const g = Math.sin(2 * Math.PI * frac * 2.5 + 0.33) * 0.5 + 0.5;
    const b = Math.sin(2 * Math.PI * frac * 2.5 + 0.67) * 0.5 + 0.5;
    
    // Boost contrast
    const scale = 1.2;
    return [
        Math.floor(r * 255 * scale),
        Math.floor(g * 255 * scale),
        Math.floor(b * 255 * scale)
    ];
}
```

This gives a nice rainbow-like gradient. But I want something more "premium" looking. Let me try a different approach - a palette with defined color stops:

```javascript
const palette = [
    [0, 0, 0],       // black
    [0, 0, 128],     // dark blue
    [0, 128, 255],   // blue
    [128, 0, 255],   // purple
    [255, 0, 128],   // magenta
    [255, 128, 0],   // orange
    [255, 255, 128], // yellow
    [255, 255, 255], // white
];
```

And interpolate between stops based on the smooth iteration value.

This is getting complex. Let me just go with a clean sine-based palette and make sure it looks good.

Actually, let me think about this more carefully. The most visually stunning Mandelbrot renders often use carefully crafted palettes. Let me use a palette that transitions through deep blues, purples, pinks, oranges, and warm colors - like a "cosmic" or "neon" palette.

I'll define it as a series of color stops and use linear interpolation:

```javascript
const STOPS = [
    { t: 0.0, r: 0, g: 0, b: 0 },
    { t: 0.05, r: 10, g: 0, b: 30 },
    { t: 0.15, r: 20, g: 0, b: 80 },
    { t: 0.3, r: 30, g: 20, b: 150 },
    { t: 0.45, r: 80, g: 30, b: 200 },
    { t: 0.55, r: 150, g: 40, b: 220 },
    { t: 0.65, r: 220, g: 60, b: 180 },
    { t: 0.75, r: 255, g: 100, b: 80 },
    { t: 0.85, r: 255, g: 180, b: 40 },
    { t: 0.95, r: 255, g: 240, b: 100 },
    { t: 1.0, r: 255, g: 255, b: 220 },
];
```

This creates a palette that goes from dark purple/blue through magenta, pink, orange, to yellow/white. Combined with the smooth coloring, this should look beautiful.

Let me implement this properly. The smooth iteration count gives a value that increases as we get closer to the boundary. The fractional part of this value determines the color within each iteration band, giving smooth transitions.

For the final color, I'll use the fractional part of the smooth iteration to index into the palette:

```javascript
const frac = smoothIter - Math.floor(smoothIter);
// frac is in [0, 1), use it to interpolate in the palette
```

Wait, but the smooth iteration can be larger than the number of palette stops. I should normalize it. Actually, the fractional part alone gives a nice smooth cycling through the palette. The integer part determines which iteration band we're in, and the fractional part gives the smooth color within that band.

But if I just use the fractional part, all iteration bands will have the same color pattern, which might look repetitive. To add variety, I can use the full smooth value:

```javascript
// Map smoothIter to palette index
const paletteIndex = smoothIter / maxIter * (palette.length - 1);
// Or use the fractional part for cyclic coloring
const frac = smoothIter - Math.floor(smoothIter);
```

Using the fractional part gives cyclic/smooth coloring. Using the full value gives a gradient that changes as iterations increase. Both are valid approaches.

For the Mandelbrot set, the cyclic approach (using fractional part) is very common and looks great because it creates smooth bands of color. Let me use that.

But wait - if I use the fractional part alone, the palette will cycle every iteration, which means the colors repeat. This can look nice (like a smooth gradient) but might not show the depth of the fractal as well.

A common approach is to use both:
- The integer part determines the general color range
- The fractional part determines the exact shade

Or simply use the normalized smooth iteration value mapped to the palette.

Let me use the fractional part for a clean, smooth look. The palette itself provides enough variety.

OK, I've spent too long thinking about colors. Let me just write the code with a nice palette and test it.

Let me write the full HTML file now. I'll make it polished and complete.

One more thing - for the "Reset view" button, I need to restore the initial bounds. The initial bounds should show the complete Mandelbrot set with the main cardioid and surrounding lobes. I'll use:
- centerX = -0.5
- centerY = 0
- zoom = canvas.width / 3 (so the view spans ~3 units wide, from -2 to 1)

This gives the classic view of the Mandelbrot set.

Wait, I need to be more precise. If the canvas is W pixels wide and zoom is W/3, then the view spans from:
- xMin = centerX - W/(2*zoom) = -0.5 - W/(2*W/3) = -0.5 - 1.5 = -2
- xMax = centerX + W/(2*zoom) = -0.5 + 1.5 = 1

So the view spans from -2 to 1 on the real axis, which is correct for showing the full set.

For the imaginary axis:
- yMin = 0 - H/(2*zoom) = 0 - H/(2*W/3) = -H*3/(2*W)
- yMax = 0 + H*3/(2*W)

For a 16:9 display, H/W = 9/16, so yMin = -27/32 ≈ -0.84, yMax ≈ 0.84. This doesn't show the full height of the set (which goes to about ±1.5). 

Hmm, I should adjust the zoom to show the full set. If I want the view to span ±1.5 vertically, then:
- zoom = H / 3 (so the view height is 3 units)
- Then horizontally: view width = W / zoom = W * 3 / H

For a 16:9 display, W/H = 16/9, so view width = 16/9 * 3 = 48/9 ≈ 5.33 units. That shows from about -3.17 to 2.17, which is wider than needed but shows the full set.

Alternatively, I could use the minimum of (W/3, H/3) for the zoom, which would show the full set without cropping. But then there would be empty space on the sides or top/bottom.

Actually, for the "classic" Mandelbrot view, the standard is to show from (-2, -1.5) to (1, 1.5) - a 3x3 square. For a non-square display, I should fit this square into the canvas, which means using the smaller dimension to determine the zoom.

Let me use:
- zoom = Math.min(canvas.width, canvas.height) / 3

This ensures the full 3x3 view fits in the canvas, with margins on the longer dimension.

For the center, I'll use (-0.5, 0) which is the center of the Mandelbrot set.

Actually, let me reconsider. The user says "Initially show the complete main cardioid and surrounding lobes." The main cardioid is the heart-shaped region at the center of the Mandelbrot set. It extends from about (-0.75, 0) to (0.25, 0) on the real axis and about (-0.65, 0.65) on the imaginary axis. The surrounding lobes include the bulbs attached to the cardioid.

If I show the full set from (-2, -1.5) to (1, 1.5), the cardioid and lobes are visible but small. If I zoom in a bit, the cardioid becomes more prominent. But the user says "complete main cardioid AND surrounding lobes" which suggests showing both the cardioid and its surroundings, i.e., the full set.

I'll go with the full set view: center at (-0.5, 0) with zoom that shows the entire set.

Actually, let me re-read: "Initially show the complete main cardioid and surrounding lobes." I think this means the initial view should show the main cardioid (the big heart-shaped region) along with the lobes/bulbs around it. This is exactly what the classic full-set view shows. So my approach is correct.

Let me now write the code.

For the zoom factor on wheel, I'll use something like 1.15 (15% zoom per wheel tick). This gives smooth zooming. Some implementations use a fixed zoom factor like 2x per click, but a smaller factor gives more control.

Actually, many Mandelbrot explorers use a zoom factor of around 1.1 to 1.2 per scroll tick. Let me use 1.15.

For the iteration count, I'll use:
- Base iterations: 100
- Additional iterations per zoom level: 50 * log2(zoomRatio)

So at the initial view (zoomRatio = 1), iterations = 100.
At 2x zoom, iterations = 100 + 50 = 150.
At 4x zoom, iterations = 100 + 100 = 200.
At 8x zoom, iterations = 100 + 150 = 250.
At 16x zoom, iterations = 100 + 200 = 300.

I'll cap at some maximum (like 2000) to prevent excessive computation at very deep zooms.

Actually, let me use a slightly different formula. The detail in the Mandelbrot set increases as we zoom in, and we need more iterations to resolve it. A common rule of thumb is that iterations should increase proportionally to the zoom factor (not log of zoom). But that would mean at 100x zoom, we'd need 10000 iterations, which is very slow.

A better approach: iterations = baseIter * (1 + log2(zoomRatio)). This gives:
- At 1x zoom: 100 iterations
- At 2x zoom: 200 iterations
- At 4x zoom: 300 iterations
- At 8x zoom: 400 iterations
- At 16x zoom: 500 iterations

This is more reasonable. Let me cap at 1000 or so.

Actually, let me use: maxIter = Math.floor(80 + 40 * Math.log2(zoomRatio + 1))

This gives:
- zoomRatio = 1: 80 + 40 * log2(2) = 80 + 40 = 120
- zoomRatio = 2: 80 + 40 * log2(3) = 80 + 40 * 1.58 = 80 + 63 = 143
- zoomRatio = 4: 80 + 40 * log2(5) = 80 + 40 * 2.32 = 80 + 93 = 173
- zoomRatio = 8: 80 + 40 * log2(9) = 80 + 40 * 3.17 = 80 + 127 = 207
- zoomRatio = 16: 80 + 40 * log2(17) = 80 + 40 * 4.09 = 80 + 163 = 243

Hmm, this grows slowly. Let me use a faster growth:
maxIter = Math.floor(100 * Math.log2(zoomRatio + 2))

- zoomRatio = 1: 100 * log2(3) = 100 * 1.58 = 158
- zoomRatio = 2: 100 * log2(4) = 100 * 2 = 200
- zoomRatio = 4: 100 * log2(6) = 100 * 2.58 = 258
- zoomRatio = 8: 100 * log2(10) = 100 * 3.32 = 332
- zoomRatio = 16: 100 * log2(18) = 100 * 4.17 = 417

This seems reasonable. Let me cap at 2000.

Actually, I'll tune this when I see the results. Let me start with something reasonable and adjust.

Let me finalize the code now. Here's what I'll write:

```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>
        * {
            margin: 0;
            padding: 0;
            box-sizing: border-box;
        }
        
        html, body {
            width: 100%;
            height: 100%;
            overflow: hidden;
            background: #000;
            font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
        }
        
        canvas {
            display: block;
            cursor: grab;
        }
        
        canvas:active {
            cursor: grabbing;
        }
        
        #controls {
            position: fixed;
            bottom: 20px;
            left: 50%;
            transform: translateX(-50%);
            display: flex;
            align-items: center;
            gap: 16px;
            background: rgba(0, 0, 0, 0.7);
            padding: 10px 16px;
            border-radius: 8px;
            backdrop-filter: blur(10px);
            border: 1px solid rgba(255, 255, 255, 0.1);
            z-index: 10;
        }
        
        #controls button {
            background: rgba(255, 255, 255, 0.1);
            color: #fff;
            border: 1px solid rgba(255, 255, 255, 0.2);
            padding: 8px 16px;
            border-radius: 4px;
            cursor: pointer;
            font-size: 14px;
            transition: background 0.2s;
        }
        
        #controls button:hover {
            background: rgba(255, 255, 255, 0.2);
        }
        
        #info {
            color: rgba(255, 255, 255, 0.6);
            font-size: 12px;
            white-space: nowrap;
        }
        
        #loading {
            position: fixed;
            top: 0;
            left: 0;
            right: 0;
            bottom: 0;
            display: none;
            align-items: center;
            justify-content: center;
            background: rgba(0, 0, 0, 0.5);
            z-index: 20;
            font-size: 18px;
            color: white;
            letter-spacing: 0.1em;
        }
        
        #loading.active {
            display: flex;
        }
        
        #coords {
            color: rgba(255, 255, 255, 0.4);
            font-size: 11px;
            font-family: monospace;
            margin-left: 16px;
        }

        #zoomLevel {
            color: rgba(255, 255, 255, 0.4);
            font-size: 11px;
            font-family: monospace;
            margin-left: 16px;
        }
    </style>
</head>
<body>
    <canvas id="canvas"></canvas>
    
    <div id="controls">
        <button id="resetBtn">Reset view</button>
        <span id="info">Drag to pan · Scroll to zoom</span>
        <span id="zoomLevel"></span>
        <span id="coords"></span>
    </div>
    
    <div id="loading" class="">Computing...</div>
    
    <script>
        // ... implementation
    </script>
</body>
</html>
```

Now let me write the full JavaScript implementation. I'll be thorough.

Let me think about edge cases:
1. Window resize: update canvas size, re-render
2. Very high zoom: cap iterations, might have precision issues (JS double precision is ~15 digits, so at zoom > 10^14 we'd have issues, but we won't go that far)
3. Rapid repeated clicks: debounce or cancel previous renders

Let me implement all of this.

One thing I want to be careful about: when the user is dragging, I should update the view and re-render. But re-rendering on every mouse move could be slow. Instead, I'll update the view during drag and re-render after the drag ends. During the drag, I'll just show a dragged state (maybe with a visual indicator).

Actually, the user says "Drag pans the image with the pointer" - this implies real-time panning during drag. So I should re-render during drag. But with full-resolution rendering, this would be very slow.

Let me implement a two-speed approach:
1. During active drag: render at half resolution (or quarter) for responsiveness
2. After drag ends: render at full resolution

For half-resolution rendering, I'll compute every other pixel and use image smoothing to fill in the gaps. Or I'll render to a smaller canvas and scale it up.

Actually, the simplest approach: render at full resolution but with fewer iterations during drag. The image builds up faster because there's less computation per pixel. After the drag ends, render with full iterations.

Hmm, but fewer iterations means less detail, which defeats the purpose of panning to see new areas.

Let me just go with full-resolution rendering during drag, but use requestAnimationFrame to yield control. The rendering will take some time but the UI stays responsive. The user will see the image progressively updating during the drag.

Actually, for the best UX, let me implement this:
1. On drag start: record the starting position, set `isDragging = true`
2. On drag move: update the view center based on the drag delta, cancel any ongoing render, start a new render at half resolution
3. On drag end: set `isDragging = false`, start a full-resolution render

For half-resolution rendering, I'll render to a canvas that's half the size and then draw it scaled up with image smoothing.

Let me implement this.

Actually, this is getting really complex. Let me simplify:

1. Always render at full resolution
2. Use chunked rendering with requestAnimationFrame for responsiveness
3. On navigation (drag or wheel), cancel the previous render and start a new one
4. The render progressively updates the canvas

This is clean and simple. The chunked rendering means the UI stays responsive, and the progressive update means the user sees the image being built.

Let me go with this approach. I'll optimize the Mandelbrot computation to be as fast as possible (using local variables, avoiding function calls in the inner loop, etc.).

Here's the final implementation plan:

```javascript
const canvas = document.getElementById('canvas');
const ctx = canvas.getContext('2d');
const loadingEl = document.getElementById('loading');
const resetBtn = document.getElementById('resetBtn');
const zoomLevelEl = document.getElementById('zoomLevel');
const coordsEl = document.getElementById('coords');

let W, H;
let view = { cx: -0.5, cy: 0, zoom: 1 };
const BASE_VIEW_WIDTH = 3; // initial view spans 3 units (from -2 to 1)

let renderReq = null; // request ID for cancellation
let isRendering = false;

function init() {
    resize();
    window.addEventListener('resize', resize);
    canvas.addEventListener('mousedown', onMouseDown);
    canvas.addEventListener('mousemove', onMouseMove);
    canvas.addEventListener('mouseup', onMouseUp);
    canvas.addEventListener('mouseleave', onMouseUp);
    canvas.addEventListener('wheel', onWheel, { passive: false });
    resetBtn.addEventListener('click', resetView);
    render();
}

function resize() {
    W = window.innerWidth;
    H = window.innerHeight;
    canvas.width = W;
    canvas.height = H;
    // Adjust zoom to maintain view
    view.zoom = Math.min(W, H) / BASE_VIEW_WIDTH;
    updateInfo();
    if (!isRendering) render();
}

function resetView() {
    view.cx = -0.5;
    view.cy = 0;
    view.zoom = Math.min(W, H) / BASE_VIEW_WIDTH;
    updateInfo();
    render();
}

function screenToComplex(sx, sy) {
    const x = view.cx + (sx - W/2) / view.zoom;
    const y = view.cy + (sy - H/2) / view.zoom;
    return { x, y };
}

function zoomAt(sx, sy, factor) {
    const p = screenToComplex(sx, sy);
    view.zoom *= factor;
    view.cx = p.x - (sx - W/2) / view.zoom;
    view.cy = p.y - (sy - H/2) / view.zoom;
    updateInfo();
    render();
}

let dragStart = null;
let dragViewStart = null;

function onMouseDown(e) {
    dragStart = { x: e.clientX, y: e.clientY };
    dragViewStart = { cx: view.cx, cy: view.cy };
    canvas.style.cursor = 'grabbing';
}

function onMouseMove(e) {
    if (!dragStart) return;
    const dx = e.clientX - dragStart.x;
    const dy = e.clientY - dragStart.y;
    view.cx = dragViewStart.cx - dx / view.zoom;
    view.cy = dragViewStart.cy - dy / view.zoom;
    updateInfo();
    render();
}

function onMouseUp() {
    dragStart = null;
    dragViewStart = null;
    canvas.style.cursor = 'grab';
}

function onWheel(e) {
    e.preventDefault();
    const factor = e.deltaY < 0 ? 1.15 : 1/1.15;
    zoomAt(e.clientX, e.clientY, factor);
}

function updateInfo() {
    const zoomRatio = view.zoom / (Math.min(W, H) / BASE_VIEW_WIDTH);
    zoomLevelEl.textContent = `Zoom: ${zoomRatio.toFixed(2)}x`;
    coordsEl.textContent = `Center: (${view.cx.toFixed(6)}, ${view.cy.toFixed(6)})`;
}

function render() {
    if (isRendering) {
        // Cancel previous render
        // We can't easily cancel a running render, so we'll just start a new one
        // and let the old one finish (its result will be overwritten)
    }
    isRendering = true;
    loadingEl.classList.add('active');
    
    const imageData = ctx.createImageData(W, H);
    const data = imageData.data;
    
    const xMin = view.cx - W / (2 * view.zoom);
    const xMax = view.cx + W / (2 * view.zoom);
    const yMin = view.cy - H / (2 * view.zoom);
    const yMax = view.cy + H / (2 * view.zoom);
    
    const zoomRatio = view.zoom / (Math.min(W, H) / BASE_VIEW_WIDTH);
    const maxIter = Math.min(2000, Math.floor(100 + 50 * Math.log2(zoomRatio + 1)));
    
    let completed = 0;
    const total = W * H;
    
    function processChunk() {
        if (renderReq !== null) {
            // A newer render has been requested, stop this one
            isRendering = false;
            loadingEl.classList.remove('active');
            return;
        }
        
        const chunkSize = 5000;
        const start = completed;
        const end = Math.min(start + chunkSize, total);
        
        for (let i = start; i < end; i++) {
            const px = i % W;
            const py = (i / W) | 0;
            
            const cx = xMin + (px / W) * (xMax - xMin);
            const cy = yMin + (py / H) * (yMax - yMin);
            
            const iter = mandel(cx, cy, maxIter);
            const idx = i * 4;
            
            if (iter < 0) {
                data[idx] = 0;
                data[idx+1] = 0;
                data[idx+2] = 0;
                data[idx+3] = 255;
            } else {
                const color = palette(iter, maxIter);
                data[idx] = color[0];
                data[idx+1] = color[1];
                data[idx+2] = color[2];
                data[idx+3] = 255;
            }
        }
        
        completed = end;
        ctx.putImageData(imageData, 0, 0);
        
        if (completed < total) {
            renderReq = requestAnimationFrame(processChunk);
        } else {
            isRendering = false;
            loadingEl.classList.remove('active');
            renderReq = null;
        }
    }
    
    renderReq = requestAnimationFrame(processChunk);
}

function mandel(cx, cy, maxIter) {
    let x = 0, y = 0;
    let x2 = 0, y2 = 0;
    let iter = 0;
    while (x2 + y2 <= 4 && iter < maxIter) {
        y = 2 * x * y + cy;
        x = x2 - y2 + cx;
        x2 = x * x;
        y2 = y * y;
        iter++;
    }
    if (iter >= maxIter) return -1;
    
    // Smooth iteration count
    const mag = x2 + y2;
    const smooth = iter + 1 - Math.log(Math.log(mag)) / Math.LN2;
    return smooth;
}

function palette( smoothIter, maxIter) {
    // Use the fractional part for smooth color cycling
    const frac = smoothIter - Math.floor(smoothIter);
    
    // Beautiful palette using sine waves
    const r = Math.sin(2 * Math.PI * frac * 2.5 + 0.0) * 0.5 + 0.5;
    const g = Math.sin(2 * Math.PI * frac * 2.5 + 0.33) * 0.5 + 0.5;
    const b = Math.sin(2 * Math.PI * frac * 2.5 + 0.67) * 0.5 + 0.5;
    
    return [Math.floor(r * 255), Math.floor(g * 255), Math.floor(b * 255)];
}
```

Hmm wait, I realize the palette function using sine waves will produce values centered around 128 (mid-gray), which might not look great. Let me adjust to get more vibrant colors.

Actually, the sine-based palette with `* 0.5 + 0.5` maps to [0, 1], and then `* 255` maps to [0, 255]. The colors will cycle through the full range. This is a classic approach and looks good.

But I want more control. Let me use a custom palette with defined color stops for a more premium look.

Let me define a nice palette:

```javascript
const PALETTE_STOPS = [
    { t: 0.0, r: 0, g: 0, b: 0 },
    { t: 0.1, r: 0, g: 0, b: 60 },
    { t: 0.2, r: 0, g: 20, b: 120 },
    { t: 0.3, r: 0, g: 60, b: 180 },
    { t: 0.4, r: 0, g: 120, b: 220 },
    { t: 0.5, r: 40, g: 160, b: 240 },
    { t: 0.6, r: 120, g: 180, b: 200 },
    { t: 0.7, r: 200, g: 140, b: 140 },
    { t: 0.8, r: 240, g: 100, b: 60 },
    { t: 0.9, r: 255, g: 160, b: 40 },
    { t: 1.0, r: 255, g: 220, b: 120 },
];

function palette(frac) {
    // Find the two stops to interpolate between
    for (let i = 0; i < PALETTE_STOPS.length - 1; i++) {
        if (frac >= PALETTE_STOPS[i].t && frac < PALETTE_STOPS[i+1].t) {
            const t0 = PALETTE_STOPS[i].t;
            const t1 = PALETTE_STOPS[i+1].t;
            const f = (frac - t0) / (t1 - t0);
            return [
                Math.floor(PALETTE_STOPS[i].r + (PALETTE_STOPS[i+1].r - PALETTE_STOPS[i].r) * f),
                Math.floor(PALETTE_STOPS[i].g + (PALETTE_STOPS[i+1].g - PALETTE_STOPS[i].g) * f),
                Math.floor(PALETTE_STOPS[i].b + (PALETTE_STOPS[i+1].b - PALETTE_STOPS[i].b) * f),
            ];
        }
    }
    return [255, 220, 120]; // fallback
}
```

This gives a custom gradient from dark blue through cyan, blue, purple, pink, orange to yellow. This should look beautiful.

But wait, the `frac` value from the smooth iteration is in [0, 1). If the smooth iteration is, say, 50.5, then frac = 0.5. This means the color will always cycle through the same palette for every iteration band. This is the "cyclic" coloring approach and it looks good for the Mandelbrot set.

However, I might want to also vary the color based on the iteration number itself (not just the fractional part) to show more depth. Let me use a combination:

```javascript
const iterFloor = Math.floor(smoothIter);
const frac = smoothIter - iterFloor;
const iterNorm = Math.min(1, iterFloor / maxIter);
```

And then mix the palette based on both frac and iterNorm. But this adds complexity. Let me start with just the frac-based palette and see how it looks.

Actually, you know what, let me just use a really nice implementation. I'll use the fractional part for color cycling through a beautiful palette, and use the iteration count to modulate brightness or saturation for added depth.

OK, I'm overthinking this. Let me write the code and test it. I can always adjust the palette later.

Let me also think about one more thing: the `renderReq` cancellation mechanism. When a new navigation starts during a render, I want to cancel the old render. My current approach uses `renderReq` to track the latest requestAnimationFrame ID. But requestAnimationFrame callbacks can't be cancelled once they've started executing. The best I can do is check in the callback if a newer render has been requested.

Actually, with requestAnimationFrame, I can use `cancelAnimationFrame(renderReq)` to cancel a pending frame. But if the callback is already executing, I can't cancel it. So I'll use a flag:

```javascript
let currentRenderId = 0;

function render() {
    currentRenderId++;
    const myId = currentRenderId;
    // ... in the chunk callback:
    if (currentRenderId !== myId) return; // newer render requested
}
```

This is cleaner. Let me use this approach.

OK, let me finalize and write the code now. I'll make it clean, well-commented, and functional.

One more consideration: for very deep zooms, JavaScript's double-precision floating point (53 bits of mantissa) starts to run out of precision. At zoom levels beyond about 10^14, the coordinates become quantized. But for this explorer, we probably won't go that deep. I'll cap iterations at 2000 to keep rendering times reasonable.

Let me also add a nice touch: show the current zoom level and center coordinates in the UI.

Now let me write the complete HTML file.

Actually, I want to reconsider the initial view. The user says "Initially show the complete main cardioid and surrounding lobes." Let me think about what this means precisely.

The Mandelbrot set's main cardioid is centered around c = 0 and extends to about c = 0.25 on the right. It has a cusp at c = 0.25. The cardioid has a boundary given by the parametric equation:
c(t) = (e^(it) * (1 - e^(it)/2)) / 2 ... actually, the cardioid boundary is:
c(t) = (e^(it) - 1/4 * e^(2it)) / 2 ... something like that.

Anyway, the main cardioid is the large heart-shaped region at the center. "Surrounding lobes" refers to the circular bulbs attached to the cardioid (the period-2 bulb at c = -1, the period-3 bulbs at the top and bottom, etc.).

To show the "complete main cardioid and surrounding lobes," I should show a view that includes the cardioid and several of its surrounding bulbs. The classic view from (-2, -1.5) to (1, 1.5) shows all of this, plus more.

Alternatively, I could zoom in slightly to make the cardioid more prominent. For example, a view from (-1.5, -1) to (0.5, 1) would show the cardioid and its immediate surroundings more clearly.

But I think the user wants the classic full-set view. Let me go with that.

Wait, actually, re-reading again: "Initially show the complete main cardioid and surrounding lobes." I think "complete" modifies "main cardioid" - i.e., show the entire main cardioid (not cropped) along with the surrounding lobes. This is exactly what the classic view does.

OK, I'm going with the classic view: center at (-0.5, 0), zoom that shows the full set.

Let me write the code now. For real this time.

One more thought: for the palette, let me use a really nice one. I'll create a palette that goes through deep space colors: black → deep purple → blue → teal → green → gold → orange → red → white. This creates a "cosmic" feel that's very popular for Mandelbrot renders.

Actually, let me use a palette that's proven to look great. I'll use the "Ultra Fractal" style palette or something similar. But since I can't use external resources, I'll define my own.

Let me use a simple but effective approach: hue cycling with high saturation and moderate lightness. This creates vibrant, colorful renders.

```javascript
function palette(frac) {
    // Convert hue (0-1) to RGB
    const hue = frac;
    const saturation = 0.8;
    const lightness = 0.5 + 0.3 * (1 - frac);
    
    // HSL to RGB
    const h = hue * 360;
    const s = saturation;
    const l = lightness;
    
    const c = (1 - Math.abs(2 * l - 1)) * s;
    const x = c * (1 - Math.abs((h / 60) % 2 - 1));
    const m = l - c / 2;
    
    let r, g, b;
    if (h < 60) { r = c; g = x; b = 0; }
    else if (h < 120) { r = x; g = c; b = 0; }
    else if (h < 180) { r = 0; g = c; b = x; }
    else if (h < 240) { r = 0; g = x; b = c; }
    else if (h < 300) { r = x; g = 0; b = c; }
    else { r = c; g = 0; b = x; }
    
    return [
        Math.floor((r + m) * 255),
        Math.floor((g + m) * 255),
        Math.floor((b + m) * 255),
    ];
}
```

This gives a rainbow-like palette with varying lightness. The lightness decreases for higher iteration values (points closer to the boundary), creating a nice depth effect.

Hmm, actually the lightness variation might make distant points (low iterations) too bright and near-boundary points too dark. Let me adjust:
- Use high lightness for all points (0.6-0.7)
- Vary hue for color cycling
- Maybe vary saturation slightly

Let me simplify:

```javascript
function palette(frac) {
    // Hue cycling with fixed saturation and lightness
    const h = frac * 360;
    const s = 0.85;
    const l = 0.55;
    
    // HSL to RGB (simplified)
    // ... 
}
```

This gives consistent brightness with cycling colors. Simple and effective.

OK, I'm going to write the code now. Final decision on the palette: I'll use a custom multi-stop gradient for a premium look, interpolated based on the fractional part of the smooth iteration.

Let me define the palette as an array of RGB stops and interpolate between them:

Actually, I just realized I should test this in the browser to see how it looks. Let me write the code, run it, and iterate.

Let me write a complete, polished implementation now.

For the palette, I'll use this approach: define an array of color stops (each with t, r, g, b), and for a given t value, find the two adjacent stops and linearly interpolate. This gives full control over the color gradient.

Here's my palette (inspired by popular Mandelbrot color schemes):

```javascript
const PALETTE = [
    { t: 0.00, r: 0,   g: 0,   b: 0 },
    { t: 0.05, r: 15,  g: 0,   b: 30 },
    { t: 0.15, r: 30,  g: 0,   b: 80 },
    { t: 0.25, r: 50,  g: 10,  b: 140 },
    { t: 0.35, r: 60,  g: 40,  b: 190 },
    { t: 0.45, r: 70,  g: 80,  b: 220 },
    { t: 0.55, r: 90,  g: 130, b: 230 },
    { t: 0.65, r: 140, g: 170, b: 210 },
    { t: 0.75, r: 210, g: 

Now let me run this in the browser to check it.

I don't know the exact actions available in the browser tool. Let me check the function signature again:

```
type browser = (_: {
// action: any of
//     ["reload", {target: string?}],
//     ["inspect", {}],
//     ["screenshot", {}],
//     ["motion", {}],
//     ["click", {x: number, y: number}],
//     ["drag", {x: number, y: number, toX: number, toY: number}],
//     ["key", {text: string}],
//     ["type", {text: string}],
//     ["scroll", {delta: number}],
// }) => any;
```
So valid actions are: reload, inspect, screenshot, motion, click, drag, key, type, scroll.

To "open" a file, I might need to use `reload` with a target, or maybe `inspect` will open it. Let me try `reload` with the path as target. Actually, looking at the reload action: `["reload", {target: string?}]` - this might reload a page. But I need to open the file first.

Let me try `inspect` - maybe that opens the browser with the current page.

Actually, looking at the cwd: `/tmp/job-ypXmho`, and I just created `index.html` there. Let me try `reload` with target as the file path, or maybe `inspect` to see what's there.

Let me try `inspect` first to see if there's a browser page already open.

The page is running. I can see the DOM shows the controls with "Reset view", "Drag to pan · Scroll to zoom", and the rendering indicator is showing. Let me take a screenshot to see the visual output.

The screenshot tool doesn't support images. That's fine. Let me check the console for any errors and test the functionality.

The console shows just a sandbox warning, no errors. The DOM shows the controls are working. Let me now test the functionality:

1. Check that the Mandelbrot set renders correctly
2. Test zoom centered on cursor
3. Test pan
4. Test reset view

Since I can't see the screenshot, I'll need to verify through the DOM and console. Let me check if the canvas is rendering by examining its properties.

Actually, the DOM shows "Rendering..." which means the render is in progress. Let me wait a moment and check again to see if it completed.

Let me check the DOM again to see if rendering completed and the canvas has content.

Good - the "Rendering..." indicator is gone, which means the render completed. The controls show:
- Reset view button
- "Drag to pan · Scroll to zoom" info
- Zoom: 1.00x
- Center: (-0.500000, 0.000000)

Now let me test the functionality. Let me simulate a wheel zoom at a specific point to verify it works. I'll use the click/drag/key actions to test.

First, let me test a wheel zoom. I can use the wheel event by scrolling. But the browser tool doesn't have a direct wheel action. Let me check what's available...

The browser tool has: reload, inspect, screenshot, motion, click, drag, key, type, scroll.

There's a `scroll` action with `delta: number`. Let me try that to simulate wheel scrolling.

Actually, let me first check if the canvas has rendered content by looking at the canvas element's properties.

Good. Now let me test the interactive functionality through the browser. Let me use `scroll` to simulate wheel zoom, and `drag` to simulate panning.

Let me test:
1. Wheel zoom at a point
2. Pan via drag
3. Reset view

Let me start by testing the wheel zoom. The scroll action takes a delta parameter. Let me try scrolling at the center of the canvas.

The wheel zoom worked! The zoom increased to 1.15x and the center shifted to (-0.793478, -0.195652). This is because the scroll happened at some point on the canvas, and the zoom is centered on that point.

The "Rendering..." indicator is showing again, which means the re-render was triggered.

Let me wait for the render to complete and then check the new zoom level and center.

Let me inspect again to see if rendering completed.

Rendering completed. Now let me test zooming further into a recognizable boundary point. A good point to zoom into is the boundary of the main cardioid near the cusp at (0.25, 0), or the period-2 bulb at (-1, 0), or the seahorse valley.

Let me zoom into the area around (-0.75, 0) which is near the boundary of the main cardioid, or the area around (-1.25, 0) which is in the seahorse valley.

Actually, let me zoom into a point that should show interesting detail. The point (-0.7269, 0.1889) is near the boundary. Or I could zoom into (0.25, 0) which is the cusp of the cardioid - very interesting boundary point.

Let me zoom in a few times at the center of the canvas to see the detail. The scroll action doesn't let me specify the position, so it scrolls at whatever position the browser defaults to (probably center).

Let me do a few more scrolls to zoom deeper.

Good, zooming deeper. The zoom is now 1.32x and the center has shifted. Let me do a few more scrolls to zoom deeper and see more detail.

Zoom is now 1.52x. Let me wait for rendering and then zoom deeper. Let me do a few more scrolls.

Let me check the render status and zoom deeper.

Render completed. Now let me test the drag-to-pan functionality and then test reset view.

Let me use the `drag` action to pan the view. I'll drag from the center to the right to pan right.

The drag worked! The center shifted from (-1.270588, -0.513726) to (-1.763726, -0.513726). That's a shift of -0.493138 in the x direction, which makes sense for a drag of 200 pixels to the right (at zoom 1.52x, 200 pixels = 200/zoom = 200/1.52 ≈ 131.6 units... wait, that doesn't match.

Wait, let me recalculate. The zoom is 1.52x relative to the base zoom. The base zoom is min(W, H) / 3. If W ≈ 1200 and H ≈ 800 (assuming a viewport), then baseZoom = 800/3 ≈ 266.67. Current zoom = 1.52 * 266.67 ≈ 405.3 pixels per unit.

A drag of 200 pixels to the right would shift the view by 200/405.3 ≈ 0.493 units to the left (since panning right shows content to the left). So the center should shift from -1.270588 to -1.270588 - 0.493 = -1.763588 ≈ -1.763726. That matches!

So the pan is working correctly.

Now let me wait for the render to complete after the pan, then test the reset view.

Let me inspect to confirm rendering completed after the pan.

Good, rendering completed after the pan. Now let me test the Reset view button. I'll click on it.

Hmm, the click didn't seem to trigger the reset. The zoom and center are still the same. Maybe I clicked the wrong position. The controls are at the bottom center of the screen. Let me try clicking at a different position. The viewport is 1200x800 based on the coordinates I used earlier. The controls are at bottom: 20px, left: 50%, transform: translateX(-50%). 

The button "Reset view" is the first element in the controls div. Let me estimate its position. The controls are at the bottom center. With a 1200px wide viewport, the controls would be at approximately x=500 to x=700 (centered, with some width). The button would be near the left side of the controls.

Let me try clicking at x=530, y=750 (near the bottom left of the controls area).

Still not working. The click might not be registering on the button. Let me check the DOM more carefully to understand the layout. Perhaps I need to find the exact position of the button.

Actually, looking at the DOM output, it shows the text content of the page. The controls div contains:
- button: "Reset view"
- span: "Drag to pan · Scroll to zoom"
- span: "Zoom: 1.52x" 
- span: "Center: (-1.763726, -0.513726)"

The DOM output doesn't give me the exact positions. Let me try to use the `inspect` action to get more details about the elements.

Actually, wait - maybe the click is happening but the render is triggered and the DOM hasn't updated yet. Let me wait and check again.

Actually, looking at the inspect output, it shows the current state of the DOM. If the reset had been triggered, the center would have changed back to (-0.5, 0) and zoom to 1.00x. Since it hasn't changed, the click likely didn't hit the button.

Let me try a different approach - use a larger click area or try different coordinates. Let me first get the viewport dimensions.

Actually, the viewport is likely 1200x800 as mentioned in the system prompt. Let me calculate the button position more carefully.

The controls div is at:
- bottom: 20px → y = 800 - 20 - controlsHeight
- left: 50% → x = 600
- transform: translateX(-50%) → shifts the left edge to center

The controls have padding: 10px 18px, so the inner width is about 1200 - 36 = 1164... no wait, the controls div can be any width based on content.

Let me estimate: the button "Reset view" is about 80px wide, plus padding. The info text is about 150px. The zoom level is about 100px. The coords are about 200px. Total width ≈ 530px + gaps (14px * 3 = 42px) ≈ 572px. With padding 18px * 2 = 36px, total ≈ 608px.

The controls div would be centered, so x ranges from 600 - 304 = 296 to 600 + 304 = 904.

The button would be near the left edge of the controls, so x ≈ 296 + 18 (padding) = 314 to 314 + 80 = 394.

The y position: bottom: 20px, height ≈ 10 (padding top) + 7 (button height) + 10 (padding bottom) = 27px. So y ranges from 800 - 20 - 27 = 753 to 753 + 27 = 780.

The button is in the top part of the controls, so y ≈ 753 + 10 (padding) = 763 to 763 + 7 = 770.

So clicking at x=350, y=765 should hit the button. Let me try that.

The reset view button worked! The zoom is now 1.00x and the center is back to (-0.500000, 0.000000). The "Rendering..." indicator shows that a re-render was triggered.

Let me wait for the render to complete and then verify the initial framing matches.

Let me verify the final state after reset.

The reset view works perfectly. The view is back to the initial state: Zoom 1.00x, Center (-0.500000, 0.000000).

Now let me do a more comprehensive test. Let me:
1. Zoom into a recognizable boundary point (like the cusp at 0.25, 0 or the seahorse valley)
2. Verify it stays near the cursor while additional detail is rendered
3. Pan the view
4. Use Reset view and compare with initial framing

Let me zoom into a specific point. I'll use the scroll action to zoom. But I need to control where the zoom is centered. The scroll action just provides a delta, and the zoom is centered on the cursor position. But I'm not sure where the cursor is positioned when I use scroll.

Let me think about this differently. I'll do multiple scrolls to zoom deeper, then check if the center coordinates make sense (they should converge to the cursor position).

Actually, the scroll action probably uses the current mouse position. Since I haven't moved the mouse, it's probably at the last click position (350, 765) or maybe at the center of the viewport.

Let me just do several scrolls and observe the center coordinates. If the zoom is centered on a fixed point, the center coordinates should converge to that point.

Let me zoom in more aggressively. I'll do 5-6 scrolls to get to about 2x zoom.

Hmm, the zoom didn't change. It's still 1.00x. Maybe the scroll action needs a larger delta, or maybe it's not working properly after the reset. Let me try a larger delta.

Still not working. Maybe the scroll position is at a place where the wheel event isn't being triggered, or maybe the canvas doesn't have focus. Let me try clicking on the canvas first to give it focus, then scrolling.

Let me try scrolling again after clicking on the canvas.

Now it worked! The zoom increased to 1.15x. But the center is still at (-0.5, 0). This means the scroll happened at the exact center of the canvas (since the center didn't change, the cursor must have been at the center of the view).

Wait, but I clicked at (600, 400) which is the center of a 1200x800 viewport. The center of the Mandelbrot view is (-0.5, 0). So scrolling at the center of the canvas zooms in centered on (-0.5, 0), which keeps the center at (-0.5, 0). That makes sense.

Let me zoom deeper by scrolling more. Let me try 10 scrolls to get to about 4x zoom.

Let me verify the render completed, then zoom deeper.

Good. Now let me zoom deeper into a boundary point. The center is at (-0.5, 0). If I keep scrolling at the center, I'll zoom into (-0.5, 0) which is inside the Mandelbrot set (it's in the main cardioid). That won't show interesting boundary detail.

Let me instead click at a boundary point and then scroll. A good boundary point is near the cusp at (0.25, 0), or the seahorse valley near (-0.75, 0.1), or the period-2 bulb boundary near (-1, 0).

Let me click at a point that should be near a boundary, then scroll to zoom into that point.

The point (-0.7269, 0.1889) is near the boundary between the main cardioid and the period-3 bulb. Or I could use (-0.5, 0.5) which is near the top of the set.

Let me click at (750, 300) which is to the right of center and above center, then scroll. In complex coordinates, this would be:
- x = -0.5 + (750 - 600) / zoom = -0.5 + 150/266.67 = -0.5 + 0.5625 = 0.0625
- y = 0 + (300 - 400) / zoom = 0 - 100/266.67 = -0.375

Hmm, that's not near an interesting boundary. Let me calculate better.

At zoom 1.15x, the pixels per unit is 1.15 * 266.67 = 306.67. The canvas is 1200x800.

If I click at (900, 350):
- x = -0.5 + (900 - 600) / 306.67 = -0.5 + 300/306.67 = -0.5 + 0.978 = 0.478
- y = 0 + (350 - 400) / 306.67 = 0 - 50/306.67 = -0.163

That's near the right side, which is outside the set (the set ends at x=0.25). Not ideal.

Let me click at (600, 250) - above center:
- x = -0.5 + 0 = -0.5
- y = 0 + (250 - 400) / 306.67 = -150/306.67 = -0.489

That's near the bottom of the set. The set extends to about y = -1.5, so this is inside the set but near the bottom boundary area.

Actually, let me think about where the most interesting boundaries are. The seahorse valley is around (-0.75, 0.1) to (-0.75, 0.2). The cusp is at (0.25, 0). The period-2 bulb is centered at (-1, 0).

Let me click at a point that maps to approximately (-0.75, 0.15):
- x = -0.5 + (px - 600) / 306.67 = -0.75 → px - 600 = -0.25 * 306.67 = -76.67 → px = 523.33
- y = 0 + (py - 400) / 306.67 = 0.15 → py - 400 = 0.15 * 306.67 = 46 → py = 446

So clicking at (523, 446) should map to approximately (-0.75, 0.15). Let me click there and then scroll.

Now let me scroll to zoom into that point.

The zoom worked and the center shifted to (-0.532750, 0.019565). This is close to where I clicked (which mapped to approximately (-0.75, 0.15) at the old zoom level). Wait, that doesn't seem right. Let me recalculate.

At zoom 1.15x, pixels per unit = 1.15 * 266.67 = 306.67. I clicked at (523, 446).
- x = -0.5 + (523 - 600) / 306.67 = -0.5 + (-77) / 306.67 = -0.5 - 0.251 = -0.751
- y = 0 + (446 - 400) / 306.67 = 46 / 306.67 = 0.150

So I clicked at approximately (-0.751, 0.150). After zooming by 1.32/1.15 = 1.148x, the new center should be close to (-0.751, 0.150) but adjusted because the zoom changes the mapping.

Actually, the zoomAt function computes the complex point under the cursor and then adjusts the center so that point remains under the cursor after zooming. So after zooming, the cursor position (523, 446) should still map to approximately (-0.751, 0.150).

Let me verify: at zoom 1.32x, pixels per unit = 1.32 * 266.67 = 352.0.
- x = -0.532750 + (523 - 600) / 352.0 = -0.532750 + (-77) / 352.0 = -0.532750 - 0.21875 = -0.7515
- y = 0.019565 + (446 - 400) / 352.0 = 0.019565 + 46/352 = 0.019565 + 0.1307 = 0.1502

So the point (523, 446) now maps to (-0.7515, 0.1502), which is very close to where I clicked initially (-0.751, 0.150). The zoom is working correctly - the point under the cursor stays fixed.

Now let me zoom deeper. Let me do a few more scrolls.

Let me verify rendering completed, then zoom deeper.

Render completed. Now let me zoom deeper into this boundary point. Let me do several scrolls to get to about 3-4x zoom.

Good. Let me wait for render and then zoom deeper.

Let me check render status and zoom deeper.

Good. Let me zoom deeper to see more detail. Let me do a few more scrolls to get to about 3x zoom.

Let me continue zooming deeper. Let me do a few more scrolls.

Let me check and continue zooming.

Let me zoom deeper to about 4-5x to really see the detail.

Let me continue zooming and then wait for the final render. Let me do a couple more scrolls to get to about 3x.

It seems like the scroll didn't register another change. Maybe it's still rendering from the previous scroll. Let me wait and try again.

Let me check the render status.

Render completed. Now let me zoom deeper.

Getting deeper. Let me zoom a bit more and then do a final render check.

Let me check the render and then zoom deeper one more time.

Good. Now let me do one more zoom to get to about 2.65x, then test panning and reset.

Actually, let me zoom a bit more to really show the detail. Let me do 2 more scrolls.

Let me wait for the render and then test panning.

Let me verify rendering completed.

Good. Now let me test panning while at this zoomed-in view. I'll drag slightly to pan the view.

Panning works. The center shifted from (-0.642535, 0.085151) to (-0.713023, 0.085151). The shift is -0.070488 in x. At zoom 2.66x, pixels per unit = 2.66 * 266.67 = 709.33. A drag of 50 pixels to the right shifts the view by 50/709.33 = 0.0705 units to the left. So the new center x = -0.642535 - 0.0705 = -0.713035 ≈ -0.713023. This matches!

Now let me wait for the render to complete after the pan, then test the reset view to compare with the initial framing.

Let me verify the render completed after panning.

Render completed after panning. Now let me test the reset view to compare with the initial framing.

Reset view works. The view is back to Zoom 1.00x, Center (-0.500000, 0.000000), which matches the initial framing.

Let me wait for the final render to complete and then verify.

Let me do a final verification.

The reset view works correctly, restoring the initial framing (Zoom 1.00x, Center (-0.500000, 0.000000)).

Let me also test that the wheel doesn't scroll the page. I can check this by looking at the body's scroll position. If the page doesn't scroll, the wheel handler is working correctly.

Actually, I already used `e.preventDefault()` in the wheel handler, and I used `{ passive: false }` to allow preventDefault. Let me verify this is working by checking if the page scrolls when I use the scroll action.

Wait, the scroll action in the browser tool might be different from a real wheel event. Let me just verify the code has the right implementation.

Looking at my code:
```javascript
canvas.addEventListener('wheel', onWheel, { passive: false });
```

And:
```javascript
function onWheel(e) {
    e.preventDefault();
    ...
}
```

This should prevent the default scroll behavior. The `{ passive: false }` is important because modern browsers make wheel listeners passive by default, which means preventDefault is ignored. By specifying `{ passive: false }`, we can call preventDefault.

The implementation looks correct. Let me also verify the page doesn't have overflow scroll by checking the CSS:
```css
html, body {
    width: 100%; height: 100%; overflow: hidden; ...
}
```

`overflow: hidden` prevents page scrolling. So even without preventDefault, the page wouldn't scroll. But the preventDefault is still important for the fractal zoom to work correctly.

Everything looks good. Let me also check the console for any errors.

The only console message is a sandboxed iframe warning, which is not an error from my code. No JavaScript errors.

Let me now do a final summary check:

1. ✅ Mandelbrot set computation with smooth escape-time coloring
2. ✅ Distinct color for points inside the set (black)
3. ✅ Initial view shows the complete main cardioid and surrounding lobes (Zoom 1.00x, Center (-0.5, 0))
4. ✅ Dragging pans the image
5. ✅ Mouse-wheel zoom centered on cursor
6. ✅ Recompute after navigation (render is triggered on each navigation)
7. ✅ Sufficient iterations that increase with zoom (maxIter = 100 + 60 * log2(zoomRatio + 1.5), capped at 2500)
8. ✅ Controls remain responsive during rendering (chunked rendering with requestAnimationFrame)
9. ✅ Reset view button restores initial bounds
10. ✅ Wheel navigation doesn't scroll the page (preventDefault + overflow: hidden)
11. ✅ Canvas 2D used with procedural colors

The implementation is complete and working. Let me also check if there are any edge cases I should handle:

- Window resize: ✅ handled by the resize event listener
- Rapid clicks: ✅ handled by renderToken cancellation mechanism
- Empty canvas on first load: ✅ resize() is called immediately which triggers render

I think the implementation is solid. Let me verify the file is complete and readable.

Actually, wait - let me re-read the requirements one more time:

"Verify: Zoom into a recognizable boundary point and check that it stays near the cursor while additional detail is rendered."

I did this - I zoomed into the point near (-0.75, 0.15) and verified that the center coordinates converge to keep the cursor point fixed during zoom.

"Pan the view, then use Reset view and compare with the initial framing."

I did this - I panned from (-0.642535, 0.085151) to (-0.713023, 0.085151), then reset to (-0.5, 0) which matches the initial framing.

Everything checks out. The implementation is complete and correct.