The two scale factors every overlay branch needs to reproduce what
the screen shows.
On screen, overlay sizes are authored in VIEWPORT units — the
overlay manager writes font-size: <font_size × 100>vh,
width: <size[0] × 100>vw, padding: …vh — and an <img> with no
configured size lays out at its natural CSS-pixel size. None of
those are relative to the capture frame, so resolving them against
the capture canvas (as this module used to) only agrees with the
screen in the one case where the canvas exactly fills the viewport
AND the capture is exactly canvas-sized. Recording breaks both
halves of that: the offline path renders at the chosen output
height (1080p/1440p/4K), and an embedded viewer's canvas is a
fraction of the window.
So: convert to CSS pixels first (viewport-relative sizes against the
real viewport, natural image sizes as-is), then multiply by the
capture-pixels-per-CSS-pixel ratio. This is the same mapping the
HTML branch has always used for its getBoundingClientRect math.
The two scale factors every overlay branch needs to reproduce what the screen shows.
On screen, overlay sizes are authored in VIEWPORT units — the overlay manager writes
font-size: <font_size × 100>vh,width: <size[0] × 100>vw,padding: …vh— and an<img>with no configured size lays out at its natural CSS-pixel size. None of those are relative to the capture frame, so resolving them against the capture canvas (as this module used to) only agrees with the screen in the one case where the canvas exactly fills the viewport AND the capture is exactly canvas-sized. Recording breaks both halves of that: the offline path renders at the chosen output height (1080p/1440p/4K), and an embedded viewer's canvas is a fraction of the window.So: convert to CSS pixels first (viewport-relative sizes against the real viewport, natural image sizes as-is), then multiply by the capture-pixels-per-CSS-pixel ratio. This is the same mapping the HTML branch has always used for its
getBoundingClientRectmath.