Mandelbrot explorer · mistral-large-4-0

The canvas is still rendering (black). Let me wait and take a screenshot to see the fractal.

The Mandelbrot set renders beautifully — full cardioid and lobes visible, smooth gradient, distinct dark interior. Now let me test zoom centered on cursor. I'll zoom into a boundary point (e.g., the seahorse valley near -0.75, 0.1) and verify the point stays under the cursor.

The scroll didn't seem to zoom — the image looks identical and the coords still show -2, -1 (which is just the initial value since pointermove hasn't fired). The status says "Rendering…" which suggests a render was triggered. But the image looks the same. Maybe the scroll event's deltaY of -600 with factor exp(600*0.0015)=exp(0.9)≈2.46 zoom... wait, factor = exp(-deltaY * 0.0015) = exp(600*0.0015) = exp(0.9) ≈ 2.46. Then view.scale = 3 * 2.46 = 7.4 — that's zoom OUT. Hmm, deltaY negative means scroll up = zoom in typically. My formula: factor = exp(-e.deltaY * 0.0015). deltaY = -600 → factor = exp(0.9) = 2.46 → scale increases → zoom out. That's inverted! Scroll up (deltaY negative) should zoom IN (scale decreases). Wait, but the screenshot shows the same view. Maybe the render is still in progress ("Rendering…" status). The screenshot was taken immediately. Let me wait and screenshot again. Also I need to fix the zoom direction. Actually wait — looking again, the image looks identical to before. The status says "Rendering…" so it may not have finished. But also the zoom direction is wrong. Let me fix the direction first: scroll up (deltaY < 0) should zoom in, so factor should be < 1, meaning scale *= factor < 1. factor = exp(-deltaY * 0.0015): deltaY=-600 → exp(+0.9) > 1 → zoom out. Wrong. Should be factor = exp(deltaY * 0.0015) so deltaY=-600 → exp(-0.9)=0.41 → zoom in. Let me fix. Also, the browser scroll tool may send deltaY differently. Let me fix the sign and re-test.

Still rendering. Let me wait a moment and take a screenshot to confirm the initial render completes.

Good, initial render works. Now let me test zoom. I'll move the mouse to a boundary point first (to update coords), then scroll to zoom. Let me move to a point on the boundary — e.g., the seahorse valley area around (-0.75, 0.1). In screen coords: x = (-0.75 - (-2))/3 * 1200 = (1.25/3)*1200 = 500. y: complex y=0.1 → screen y = (0 - 0.1)/2 * 800 + 400... let me compute: y0 = cy - h/2 = 0 - 1 = -1. screen_y = (cy_complex - y0)/h * H = (0.1 - (-1))/2 * 800 = 1.1/2*800 = 440. So (500, 440) is near the boundary between the cardioid and the period-2 bulb — a good recognizable boundary point. Let me move mouse there, then scroll up to zoom in, and check the coords stay near the same complex point.

The drag with same start/end point acted as a pointermove — coords now show x: -0.750000 y: 0.100000, which is exactly the boundary point (cusp between cardioid and period-2 bulb). The "Rendering…" status is odd — a zero-distance drag shouldn't trigger a render... Actually pointerdown + pointerup with no movement: pointermove may have fired once with same coords, mx=my=0, so view unchanged but requestRender() called. That's fine. Now scroll up at (500, 440) to zoom in. deltaY should be negative for scroll up. Let me use delta: -600 (scroll up = zoom in).

The scroll didn't zoom — the image is identical and coords unchanged. The status says "Rendering…" which is from the earlier zero-distance drag. It seems the scroll event may not be reaching the canvas, or the browser tool's scroll isn't dispatching a wheel event on the canvas. Hmm, the status still says "Rendering…" — that render from the drag should have completed long ago (388ms). Unless... the scroll triggered a render that's queued. Actually wait — the screenshot was taken immediately after the scroll action, so "Rendering…" might be from the scroll-triggered render in progress. But the image looks identical to the unzoomed view. Let me wait and take another screenshot to see the result.

Excellent! The zoom worked! We're now zoomed into the boundary between the period-2 bulb (left) and the main cardioid (right) — the seahorse valley region near (-0.75, 0.1). The iteration count increased to 451 (from 256), showing new detail. The coords still show x: -0.750000 y: 0.100000 — the point under the cursor stayed fixed! Wait, but the coords display only updates on pointermove. The cursor is still at (500, 440), and the HUD shows the complex coords at that pixel. Since zoom is centered on cursor, the complex point under the cursor should remain (-0.75, 0.1). The HUD shows exactly that — but it might be stale from before the zoom. Let me move the mouse slightly to force a coords update and verify the point under the cursor is still ~(-0.75, 0.1). Actually, looking at the image: the cursor at (500, 440) — the boundary cusp between the two big blobs is right around x=800 in the new image... Hmm, wait. Let me think. Before zoom, the cusp between cardioid and period-2 bulb was at complex (-0.75, 0), which was at screen x=500. After zooming centered at (500,440), that cusp should still be at screen (500, 440). In the new image, the cusp (where the two black blobs nearly touch) appears to be around x=800, y=440. Hmm, that's not at 500. Wait, let me look more carefully. The image shows the period-2 bulb on the left (centered ~x=200) and the cardioid edge on the right (starting ~x=820). The gap between them at y=440 is around x=800. Hmm, but the zoom was centered at (500, 440) which was complex (-0.75, 0.1). Actually wait — the cusp between the cardioid and period-2 bulb is at exactly (-0.75, 0). The point (-0.75, 0.1) is slightly above the cusp, in the seahorse valley. After zoom, the point under the cursor (500,440) should still map to (-0.75, 0.1). Looking at the image at (500, 440): that's in the blue region between the bulb and cardioid — the seahorse valley with filaments. That looks plausible! The valley region is around x=500-800 at y=440. Yes, (500,440) is in the blue filament region. Let me verify by moving the mouse a tiny bit to force a coord update. I'll move to (501, 440) — but that might trigger... no, just a pointermove, no drag. Actually a "drag" action with tiny movement would pan slightly. Let me instead use a move — but the browser tool only has drag. A drag from (500,440) to (502,440) would pan by 2px — negligible but would change coords slightly. Actually, the coords display updates on pointermove regardless of dragging. A tiny drag of 2px would pan by 2/1200 * scale — tiny. That's acceptable for verification. Actually, better: let me verify the zoom-centering mathematically via the console. I can use the inspect action which shows DOM. The coords element updates on pointermove. Let me do a tiny drag and check coords remain ≈ (-0.75, 0.1). Actually, a cleaner test: the HUD already shows the coords at the last pointermove position. After zoom, no pointermove happened, so it shows stale value. Let me do a 1px drag and check.

The coords at (501, 440) show x: -0.749915, y: 0.100000. Before the zoom, (500, 440) was (-0.75, 0.1). After zooming in ~2.46x centered at (500,440), the point at (501,440) should be very close to (-0.75, 0.1) — just 1px to the right. The scale is now 3/2.46 ≈ 1.22 width per 1200px, so 1px ≈ 0.001 in complex units. -0.749915 vs -0.75: difference of 0.000085... hmm, that's less than 1px worth. Wait, the 1px drag also panned the view by 1px (view.cx -= mx where mx = 1/1200 * 1.22 ≈ 0.001). So the point under the cursor after the pan shifted by -0.001 in x... Let me compute: after zoom, point at (500,440) = (-0.75, 0.1) exactly (by construction). Then drag 1px right: view.cx -= 0.001017 (pan left by 1px means content moves right, so the complex coord under a fixed screen point decreases by 1px worth). New point at (501, 440): x = -0.75 + 1px_worth - 1px_worth_pan... Actually: after pan, pixelToComplex(501, 440): the view shifted so that what was at pixel 500 is now at pixel 501. So pixel 501 now shows what pixel 500 showed before the pan = (-0.75, 0.1) exactly... but we got -0.749915. Close enough — the tiny difference is because the drag panned by exactly the 1px in screen space, so pixel 501 maps to the same complex point as pixel 500 did pre-pan: (-0.75, 0.1). We got -0.749915, off by 0.000085. Hmm, that's about 0.08px. Probably rounding in my mental math of the scale (factor = exp(-600*0.0015) = exp(-0.9) = 0.4066; scale = 3*0.4066 = 1.2197; 1px = 1.2197/1200 = 0.0010164). The pan moved cx by exactly 0.0010164. And pixel 501's complex x = cx' - w/2 + 501/1200*w. Before pan at pixel 500: cx - w/2 + 500/1200*w = -0.75. After: cx' = cx - 0.0010164. pixelToComplex(501) = cx - 0.0010164 - w/2 + 501/1200*w = (cx - w/2 + 500/1200*w) + 0.0010164 - 0.0010164 = -0.75. But we got -0.749915. Difference 0.000085 ≈ 0.084 px. Hmm, small discrepancy — maybe the drag wasn't exactly 1px, or pointermove fired with slightly different coords, or the browser tool's drag moved by a slightly different amount. Either way, the point under the cursor stayed at ≈(-0.75, 0.1) — zoom centering verified. Also note the y stayed exactly 0.100000. Now the zoom centered on cursor works. The image shows the seahorse valley with new detail at 451 iterations. Next: test pan (drag), then Reset view, and compare with initial framing. Let me do a real drag pan now.

Pan worked — the view shifted (the bulb moved left/down, content followed the drag). The coords at the new cursor position (400, 500) show x: -0.666314, y: 0.067813. Let me verify: before the drag, the view was centered such that (500,440) → (-0.75, 0.1) approximately (after the 1px pan, cx shifted by -0.001). Drag from (600,400) to (400,500): dx = -200px, dy = +100px. Pan: view.cx -= (-200/1200)*w = +w/6; view.cy -= (100/800)*h = -h/8. With w≈1.2197, h≈0.8131: cx += 0.2033, cy -= 0.1016. Before drag: cx ≈ -0.75 + ... hmm let me just trust it. The point at (400,500) after pan: previously (before pan) pixel (400,500) mapped to some complex point p. After panning by (-200,+100) screen px, the content moves with the drag: the complex point now under (400,500) = the complex point that was under (600,400) before the pan. Before pan, (600,400): x = cx - w/2 + 600/1200*w = cx + 0 (since 600/1200 = 0.5, so x = cx). y = cy - h/2 + 400/800*h = cy. So (600,400) was the center (cx, cy) ≈ (-0.75+0.001+..., ...). Hmm, cx before this drag: after zoom, cx was adjusted so (500,440)→(-0.75,0.1). Center of screen (600,400) → (cx, cy). cx = -0.75 + (500-600)/1200*w = -0.75 - 0.1016 = -0.8516? Wait: pixelToComplex(500) = cx - w/2 + 500/1200*w = cx + w*(500/1200 - 0.5) = cx - w/12 = -0.75 → cx = -0.75 + 1.2197/12 = -0.75 + 0.10164 = -0.64836. Hmm wait, that doesn't seem right either. Let me redo: pixelToComplex(px) = cx - w/2 + (px/W)*w. At px=500, W=1200: = cx - w/2 + (5/12)w = cx + w(5/12 - 6/12) = cx - w/12. Set = -0.75 → cx = -0.75 + w/12 = -0.75 + 0.10164 = -0.64836. Then the 1px pan: cx -= 0.0010164 → cx = -0.64938. cy: pixelToComplex_y(440) = cy - h/2 + (440/800)*h = cy + h(0.55-0.5) = cy + h/20 = 0.1 → cy = 0.1 - 0.8131/20 = 0.1 - 0.04066 = 0.05934. After drag (-200, +100): cx -= (-200/1200)*w = +w/6 = +0.20328 → cx = -0.44610. cy -= (100/800)*h = -h/8 = -0.10164 → cy = -0.04230. Point under (400,500) after pan = point that was under (600,400) before pan = (cx_old, cy_old) = (-0.64938, 0.05934). But HUD shows (-0.666314, 0.067813). Hmm, discrepancy of ~0.017 in x and ~0.008 in y. That's about 20px and 10px worth. Hmm. Wait — maybe the drag wasn't a single move; the browser tool's drag may fire multiple pointermove events, and each one pans incrementally — that should still be equivalent. Or maybe my assumption about the exact pre-drag cx is off because the earlier 1px drag and zoom math had rounding. Actually, the discrepancy: expected (-0.64938, 0.05934), got (-0.666314, 0.067813). Diff: (-0.0169, +0.0085). In pixels: 0.0169/0.0010164 ≈ 16.6px in x, 0.0085/0.0010164 ≈ 8.4px in y. Hmm, that's suspicious — like the drag only moved ~183px instead of 200? Or my pre-drag cx estimate is wrong. Actually wait — I should double check the pre-drag state. After the zoom, I did a 1px drag from (500,440) to (501,440). That pan: cx -= (1/1200)*w = -0.0010164 → cx = -0.64836 - 0.0010164 = -0.64938. And the HUD after that showed (-0.749915, 0.1) at (501,440). Check: pixelToComplex(501) = cx - w/2 + 501/1200*w = -0.64938 + w*(501/1200 - 0.5) = -0.64938 + 1.2197*(0.4175-0.5) = -0.64938 + 1.2197*(-0.0825) = -0.64938 - 0.10063 = -0.75001. HUD showed -0.749915. Diff 0.0001 ≈ 0.1px. Fine, rounding in my w estimate (actual w = 3*exp(-0.9) = 3*0.40657 = 1.21971; close). So expected point under (400,500) after the big drag: the complex point that was under (600,400) before the drag = (cx_old, cy_old) = (-0.64938, 0.05934). HUD: (-0.666314, 0.067813). Hmm, diff is real. Unless... the drag path: the browser drag tool might do pointerdown at (600,400), move to (400,500), pointerup. Each pointermove pans. Total pan = sum of deltas = (-200, +100) px total. That's what I computed. Wait, maybe I have the y sign confused. Let me recheck with the HUD value. After drag, HUD at (400,500) = (-0.666314, 0.067813). Alternative check: what was under (400,500) BEFORE the drag? = cx_old - w/2 + 400/1200*w = -0.64938 + 1.21971*(1/3 - 1/2) = -0.64938 - 0.20329 = -0.85267. y: cy_old - h/2 + 500/800*h = 0.05934 + 0.81314*(0.625-0.5) = 0.05934 + 0.10164 = 0.16098. After pan by screen delta (-200,+100): the complex point under a fixed pixel changes by -delta: new point at (400,500) = old point at (400,500) + (complex shift). Pan: view.cx -= mx where mx = (dx_px/W)*w, dx_px = -200 → mx = -0.20329 → cx += 0.20329. So new x at pixel 400 = old x at pixel 400 + 0.20329 = -0.85267 + 0.20329 = -0.64938. Same as before. So expected -0.64938 but HUD says -0.666314. Difference: -0.666314 - (-0.64938) = -0.01693. In pixels: 0.01693/0.0010164 = 16.66 px. And y: expected 0.05934, got 0.067813, diff +0.00847 = 8.33px (in y, 1px = h/800 = 0.0010164). 16.66px and 8.33px... ratio 2:1. The drag was (-200, +100), ratio 2:1. So it's as if the pan only applied 1/12 of the drag? 200/12 = 16.67, 100/12 = 8.33. Interesting — exactly 1/12. Hmm, 12 = ? Or maybe the drag tool moved in steps and only the last step registered? Or... wait. Maybe the browser tool's drag does: pointerdown, then a single pointermove to the target, then pointerup. And my handler pans on each pointermove. That should give the full delta. OR: maybe the drag tool sends the move as multiple events and my `lastX/lastY` tracking... no, that accumulates correctly. Hmm, wait — 1/12... Actually maybe the issue: the drag tool might perform the drag over some default duration with several intermediate points, and each pointermove pans — total should still equal the full delta. Let me reconsider: maybe the discrepancy is because the render is async and the HUD coords are computed from the CURRENT view at pointermove time. During a multi-event drag, each pointermove pans and requests a render. The coords shown are from the last pointermove, using the view state at that time — which includes all pans so far. So it should be consistent. Hmm, alternatively maybe my assumption that (600,400) was the screen center is wrong: viewport is 1200x800, so center is (600,400). Yes. Wait, actually — maybe the drag tool's coordinates are not exactly what I think, or there's some scaling. Let me just directly test: do another drag and check the HUD delta. Actually, simpler: the pan clearly worked visually (the image shifted). The exact magnitude discrepancy might be due to the drag tool dispatching events with intermediate positions and my analysis being off somewhere. Let me verify pan correctness differently: drag from (600,400) to (600,400) — no. Better test: drag by a known amount and check that the complex point under the start pixel is now under the end pixel. I can check via HUD: after dragging from A to B, the HUD shows coords at B. If pan is correct, coords at B after drag = coords at A before drag. I know coords at (600,400) before the drag = (cx_old, cy_old) = (-0.64938, 0.05934) by my calc, but my calc might be wrong. Hmm, let me instead check with the HUD directly: before the drag, I didn't record the HUD at (600,400). Let me do a clean test: move to a point, note HUD, drag from that point to another, check HUD at destination equals the earlier noted value. Actually — wait. I bet the issue is the drag tool performs pointerdown at (600,400), then moves, but my pointermove handler updates `lastX/lastY` only when dragging... it does. Hmm. Actually, hold on. Let me reconsider: maybe the browser tool's "drag" action moves the mouse in N steps over time, and between steps, my async render... no, render doesn't modify view. Let me look again at the numbers. Expected (-0.64938, 0.05934), actual (-0.666314, 0.067813). What if the drag was actually from (600,400) to (416.7, 491.7)? That's 200/1.2... no. What if the tool applied the drag but the canvas coordinates are offset? The canvas is full-screen at 0,0, so clientX == canvas x. Alternatively, what if my pre-drag cx estimate is wrong because the zoom factor wasn't exactly exp(-0.9)? The scroll delta was -600, factor = exp(-600*0.0015) = exp(-0.9) = 0.406570. scale = 3 * 0.406570 = 1.219709. OK. Hmm, what if the scroll event fired multiple times? The tool's scroll with delta -600 might dispatch one wheel event with deltaY=-600, or several. If it dispatched, say, one event, fine. The status showed "451 iterations": iterationsForScale(1.2197) = 256 + log10(3/1.2197)*500 = 256 + log10(2.4596)*500 = 256 + 0.39087*500 = 256 + 195.4 = 451.4 → 451. ✓. So exactly one zoom of factor exp(-0.9) happened. Good. So pre-drag view: cx = -0.64836 (before 1px pan), then 1px pan → cx = -0.64938, cy = 0.05934. Hmm wait, let me recompute cy after zoom. Zoom centered at (500,440): before zoom, view = {cx: -0.5, cy: 0, scale: 3}. pixelToComplex(500,440) with W=1200,H=800: w=3, h=2. x = -0.5 - 1.5 + (500/1200)*3 = -2 + 1.25 = -0.75. ✓. y = 0 - 1 + (440/800)*2 = -1 + 1.1 = 0.1. ✓. After zoom: scale = 1.219709, w = 1.219709, h = 0.813139. pixelToComplex(500,440) = cx' - w/2 + (500/1200)*w = cx' + w*(5/12 - 1/2) = cx' - w/12. Set equal to -0.75: cx' = -0.75 + 1.219709/12 = -0.75 + 0.101642 = -0.648358. cy' = 0.1 - h*(440/800 - 1/2) = 0.1 - 0.813139*0.05 = 0.1 - 0.040657 = 0.059343. ✓ matches. 1px pan right: cx -= (1/1200)*1.219709 = 0.0010164 → cx = -0.649374. cy unchanged = 0.059343. Drag (-200,+100): cx -= (-200/1200)*1.219709 = +0.203285 → cx = -0.446089. cy -= (100/800)*0.813139 = -0.101642 → cy = -0.042299. Point under (400,500) = cx - w/2 + (400/1200)*w = -0.446089 + 1.219709*(1/3-1/2) = -0.446089 - 0.203285 = -0.649374. y = cy - h/2 + (500/800)*h = -0.042299 + 0.813139*0.125 = -0.042299 + 0.101642 = 0.059343. So expected HUD at (400,500): (-0.649374, 0.059343). Actual: (-0.666314, 0.067813). Diff: x: -0.01694, y: +0.00847. Ratio exactly -2. Hmm! x diff = -2 * (0.00847). And 0.00847 ≈ 8.33px worth (0.00847/0.0010164 = 8.33). So it's as if the pan applied was (-183.3, +91.7) instead of (-200, +100)? 200-183.3 = 16.7, 100-91.7 = 8.3. So the pan was short by (16.7, 8.3) px = 1/12 of the drag. OR the drag tool moved the pointer in steps and the LAST pointermove event's position was (416.7, 491.7)?? That seems weird. OR: the drag tool does pointerdown at start, then moves to end — but maybe it also does a "hover" move first, and my pointerdown... no. Hmm, wait — maybe the drag tool simulates: move to start, pointerdown, move to end (possibly in steps), pointerup. If it moves in steps, each step pans — total = full delta. Unless the tool's steps are dispatched but the page's pointermove handler... should get them all. Alternatively — maybe the tool dispatches pointerdown, then ONE pointermove to the end, then pointerup, but ALSO the coords HUD update happens on pointermove — and the HUD value I see is from the last pointermove at (400,500) — which is what I computed. So the view should reflect the full pan. Unless the pan math in my code has a bug! Let me re-read: ```js canvas.addEventListener("pointermove", (e) => { const c = pixelToComplex(e.clientX, e.clientY); coordsEl.textContent = ...; if (!dragging) return; const aspect = width / height; const w = view.scale, h = w / aspect; const mx = (e.clientX - lastX) / width * w; const my = (e.clientY - lastY) / height * h; view.cx -= mx; view.cy -= my; lastX = e.clientX; lastY = e.clientY; requestRender(); }); ``` This looks right. Hmm, but wait — `width` and `height` are CSS pixels (1200, 800). e.clientX is in CSS pixels. OK. Hmm, but actually — is it possible the drag tool's coordinates get clamped or the drag is performed with some easing where the final position isn't exactly (400,500)? The HUD shows coords at the last pointermove position. If the last pointermove was at (416.7, 491.7) instead of (400,500)... then coords would be computed at that point. Let me check: if the view pan is correct (full -200,+100) and the last pointermove was at (px, py), then HUD = pixelToComplex(px,py) = (-0.666314, 0.067813). Solve: px = (x - cx + w/2)/w * W = (-0.666314 + 0.446089 + 0.609855)/1.219709 * 1200 = (0.38963)/1.219709*1200 = 0.31944*1200 = 383.3. py = (y - cy + h/2)/h * H = (0.067813 + 0.042299 + 0.406570)/0.813139 * 800 = (0.516682)/0.813139*800 = 0.63542*800 = 508.3. Hmm, (383.3, 508.3) — not obviously meaningful. Alternatively, if the last pointermove was at (400,500) but the pan was short by 1/12... Hmm, wait. What if the drag tool performs the drag as: pointerdown at (600,400), then a series of moves, and my handler pans on each — but ALSO the browser fires a pointermove right after pointerdown at the same position (no pan), fine. What if the tool's drag includes momentum/extra events after pointerup? No. Let me think about 1/12 differently. 16.67px = 200/12. Hmm, 12... Or maybe the discrepancy is because the drag happened while a render was in progress and... no, view updates are synchronous. OR — maybe the tool's drag action actually drags from (600,400) to (400,500) but the events are: pointerdown(600,400), pointermove(400,500), pointerup(400,500). One move of (-200,+100). Pan = full. Expected HUD (-0.649374, 0.059343). Actual (-0.666314, 0.067813). Hmm, let me recompute the actual more carefully. Maybe I made an arithmetic error. Actual HUD: x: -0.666314, y: 0.067813. What if the pre-drag cx was not -0.649374? What if the 1px drag earlier didn't pan by exactly 1px? The earlier HUD after 1px drag showed (-0.749915, 0.1) at (501,440). My prediction was (-0.75001, 0.1). Diff +0.0001. So pre-1px-drag state: pixelToComplex(500,440) = ? After 1px pan (cx -= 0.0010164), pixelToComplex(501,440) = cx_new - w/2 + 501/1200*w. cx_new = cx_zoom - 0.0010164. = cx_zoom - w/2 + 501/1200*w - 0.0010164 = [cx_zoom - w/2 + 500/1200*w] + w/1200 - 0.0010164 = -0.75 + 0.0010164 - 0.0010164 = -0.75. But HUD showed -0.749915, i.e., 0.000085 higher. So either the drag was 1.084px, or... whatever, tiny. OK here's another thought: what if the drag tool moves in steps of some size and dispatches pointermove for each, but ALSO the tool first moves the mouse to the start point (600,400) — generating a pointermove (not dragging, just HUD update) — then pointerdown, then steps to (400,500). Total pan = full delta. Still full. Hmm, I wonder if the discrepancy is actually in MY expected value because the drag tool might have a different end point. Let me just do a controlled experiment: drag from (600,400) to (600,500) (pure vertical, 100px down) and check the HUD. Expected if pan correct: point under (600,500) after = point under (600,400) before = (cx, cy) = (-0.446089, -0.042299). Let me run that. Actually, wait. Before that, let me reconsider whether the pan direction/magnitude is even correct visually. In the screenshot after the drag, the period-2 bulb (which was centered around x=200) moved to around x=100-450... The bulb center before drag was at complex (-1, 0) → screen: x = (-1 - cx + w/2)/w*1200 = (-1 + 0.649374 + 0.609855)/1.219709*1200 = (0.259229)/1.219709*1200 = 255. y = (0 - 0.059343 + 0.406570)/0.813139*800 = 0.347227/0.813139*800 = 341.6. After drag (cx=-0.446089, cy=-0.042299): x = (-1 + 0.446089 + 0.609855)/1.219709*1200 = 0.055944/1.219709*1200 = 55. y = (0 + 0.042299 + 0.406570)/0.813139*800 = 0.448869/0.813139*800 = 441.6. So the bulb center should move from (255, 342) to (55, 442) — i.e., left 200px, down 100px. In the screenshot, the bulb is centered around (220, 450)? The bulb spans roughly x=10..450, y=130..770, center ≈ (230, 450). Hmm, expected center (55, 442). The y matches (450 vs 442), but x is off: 230 vs 55. That's ~175px off. Hmm, that suggests the pan in x was much less than 200px! Wait, but the screenshot was taken right after the drag while "Rendering…" — the render might not have completed, showing a stale image? No — the render is chunked and putImageData only happens at the end. So during rendering, the canvas shows the PREVIOUS frame! The screenshot shows the pre-drag image (or partially... no, putImageData is atomic at the end). So the screenshot shows the view BEFORE this drag — i.e., the post-zoom view. In the post-zoom view, bulb center at (255, 342)... but the screenshot shows the bulb centered around (230, 450). Hmm, that doesn't match either. Hold on, let me look at the screenshot again. The image shows: big bulb on the left occupying x≈10-450, y≈130-770; cardioid edge on the right starting x≈820. The cusp between them at y≈440 around x≈800. Compare with the post-zoom screenshot (before the 1px drag): bulb on left x≈10-450 y≈130-770, cardioid right. Actually the two screenshots look nearly IDENTICAL. The post-zoom screenshot and the post-drag screenshot look the same! Because the drag's render hadn't completed when the screenshot was taken — the canvas still shows the pre-drag frame. Wait, but the first screenshot after the drag showed "Rendering…" and the image looked like the zoomed view. And the second screenshot (after the 1px drag) also "Rendering…". The renders take ~1.1s. The screenshots are taken immediately after the action. So I've been seeing stale frames! So the HUD coords are the reliable indicator: after the big drag, HUD at (400,500) = (-0.666314, 0.067813). My prediction for correct pan: (-0.649374, 0.059343). Still a discrepancy of (-0.0169, +0.0085). Hmm wait, unless the drag tool dispatched the pointermove at (400,500) but ALSO the pointerdown at (600,400) triggered... no. Let me recompute assuming the pan is correct and see what pixel the HUD coords correspond to: I did that: (383.3, 508.3). Hmm. Alternatively, maybe the drag tool performs the drag with pointer events but the moves are dispatched as a sequence with the FINAL position being (400,500), and my handler pans correctly, but there were also intermediate pointermove events BEFORE pointerdown (hover moves) — those don't pan (dragging=false). Fine. Hmm, what if the tool's drag actually starts the drag from wherever the mouse currently is? The mouse was at (501,440) after the previous 1px drag! If the tool's drag action does pointerdown at the CURRENT mouse position (501,440) and drags to (400,500)... no wait, the tool takes x,y as the start. But maybe the tool first moves the mouse to (600,400) — generating a hover pointermove — then pointerdown, then drag to (400,500). That's what I assumed. But what if the tool does: pointerdown at (600,400), then move to (400,500) — but the mouse was previously at (501,440), and the tool's "move to start" happens as part of the drag with button pressed?? I.e., pointerdown at (501,440) [current position], then drag to (600,400)?? No... Let me test the hypothesis "pan was short by 1/12": Actually, let me test differently. Let me check what the HUD says now at a known pixel by doing a tiny drag (1px) and reading the HUD. The HUD after a 1px drag from (400,500) to (401,500) will show pixelToComplex(401,500) with the view panned by 1px — which equals pixelToComplex(400,500) pre-pan = the value the HUD showed after the big drag = (-0.666314, 0.067813) if pan is exact. That just re-reads the same value. Not helpful. Better: let me verify pan correctness by a clean experiment. Current view state: unknown exactly, but HUD at (400,500) = (-0.666314, 0.067813) (assuming last pointermove was exactly at (400,500)). Now drag from (400,500) to (500,500) (+100px in x). If pan is correct, the point now under (500,500) = the point that was under (400,500) = (-0.666314, 0.067813). The HUD after this drag (at (500,500)) should show exactly (-0.666314, 0.067813). If it shows something else, pan magnitude is off. Let me do that.