Question
What is a drawing surface sized to, and when is that size re-evaluated?
Today: sized once at creation from parent.getBoundingClientRect(), pinned at left/top: 0, never resized (stroke.ts:87). Two consequences: ink outside the parent's box is lost, and a parent that resizes mid-gesture draws into a stale surface. Both are in scope here.
Decide:
- The rule. Union of the parent's box and the ink's bounding box? Just the ink's box? Something viewport-derived? Whatever it is, it must state the margin the ink needs beyond its own bbox:
lineWidth / 2 for the path, pointRadius for the novice-mode start marker, and the round line caps and joins.
- When it is re-evaluated. A stroke grows continuously, so a naive "resize whenever the bbox grows" resizes on most frames. Grow-only, in chunks, on a threshold, or every frame?
- What re-evaluation costs. Setting
canvas.width/height reallocates the backing store and clears it, so every resize forces a full redraw of that surface. The draw is already rafThrottled; whether the redraw is free or a real cost is worth measuring rather than assuming.
- Device pixel ratio.
ptSize and the ctx.scale(1 / ptSize, 1 / ptSize) set up at creation have to survive a resize, and clear() currently closes over the creation-time width/height.
This is the arithmetic, not the DOM: it is answerable against whichever single element the surfaces attach to, which is why it is not blocked on #269. If the cost question turns out to need numbers, spin off a wayfinder:prototype ticket rather than guessing.
Question
What is a drawing surface sized to, and when is that size re-evaluated?
Today: sized once at creation from
parent.getBoundingClientRect(), pinned atleft/top: 0, never resized (stroke.ts:87). Two consequences: ink outside the parent's box is lost, and a parent that resizes mid-gesture draws into a stale surface. Both are in scope here.Decide:
lineWidth / 2for the path,pointRadiusfor the novice-mode start marker, and the round line caps and joins.canvas.width/heightreallocates the backing store and clears it, so every resize forces a full redraw of that surface. The draw is alreadyrafThrottled; whether the redraw is free or a real cost is worth measuring rather than assuming.ptSizeand thectx.scale(1 / ptSize, 1 / ptSize)set up at creation have to survive a resize, andclear()currently closes over the creation-timewidth/height.This is the arithmetic, not the DOM: it is answerable against whichever single element the surfaces attach to, which is why it is not blocked on #269. If the cost question turns out to need numbers, spin off a
wayfinder:prototypeticket rather than guessing.