mirror of
https://github.com/screentinker/screentinker.git
synced 2026-08-13 22:03:13 -06:00
604c390a55
Reported as "rotation doesn't work correctly". It is a geometry bug, not a rendering one, which is why it reads as mysterious. #playerContainer is pinned `inset: 0`. Rotation set width:100vh, height:100vw and rotate(90deg) — leaving the box in the TOP-LEFT corner and spinning it about its own centre rather than the viewport's. On a 1920x1080 panel the content landed at x -420..1500, y 420..1500 against a viewport of 0..1920, 0..1080: correctly rotated, wrongly placed, cropped on two edges. Tizen already did this correctly — top/left 50% plus translate(-50%,-50%) — and Android does the equivalent with translationX/Y of (w-h)/2. The web player was the odd one out, and BrightSign inherited it on top of its own hardware-plane problem. The rule now lives in server/lib/orientation-style.js, served to the player from its single source, with the arithmetic pinned by tests that compute where the rotated box actually lands on 16:9 and 5:4 panels. Three things those tests hold that are easy to get wrong: the translate must come BEFORE the rotate (transforms apply right-to-left, so reversing them rotates the correction too), 180 must NOT swap dimensions (the box already fits; swapping letterboxes it), and landscape must clear EVERY property the rotated state set (a half-reset leaves the container stuck at 100vh wide, so rotation appears to persist after switching back). 1074 pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Uaeo9MvzKoyXuN6ZsbhtkL |
||
|---|---|---|
| .. | ||
| debug-overlay.js | ||
| index.html | ||
| sw.js | ||