mirror of
https://github.com/heygen-com/hyperframes.git
synced 2026-09-01 19:42:03 +00:00
Miguel Ángel
a850e97f3d
* fix(studio): stop a resize writing size into the tween that carries scale Resizing a scale-driven element failed with "animation not found", and the element could not be saved again at all. The tween resolved for the resize's group is, for such an element, the one carrying `scale`. When it is an instant hold the code handed it straight to the size commit, which wrote `width` and `height` into it. One tween now spanned two property groups, so the parser classified it as neither — it lost its group suffix, and its id with it. Every later edit looked for a scale tween and a size tween, found a tween with no group at all, and had nothing it could address. Size goes to a size hold of its own now; the scale hold is left alone. Where the damage has already happened it is repairable: splitting the mixed tween into property groups gives back a `scale` tween and a `size` tween. * fix(studio): let the resize say whether it settled the drop point Resizing an element whose scale is an instant hold saved the new size and then snapped the element back to its authored position, every drag. Whether the caller persists the drag offset was inferred from the element's tweens: a scale-group tween meant "the resize settles its own position, hold the offset back". That is true of the scale route, which commits a scale and then measures where centre-scaling put the box. It is not true of an element whose scale is an instant hold — that has a scale-group tween and still commits width/height. So the offset was withheld, nobody wrote it, and the position tween re-asserted the authored value a frame later. The outcome carries the answer now. A resize that moved the element says so; everything else leaves the anchor to the drag, which is what already handles it. * test(studio): sweep every animated shape a resize can be handed Both faults on this branch were found one composition at a time, which is a bad way to find the third. Drives the real intercept across the cross-product of what an element's tweens can look like — scale absent, an instant hold, a real tween, longhands; size absent, a hold, a tween; position absent, a static hold, a tween; plus the 3D and rotation set a card carries and a tween that already spans two groups — and holds all 108 to the two rules that were broken: never address an animation the source does not have, and never leave a tween spanning two property groups. The server stand-in answers the way the real one does, rejecting an id it cannot find, and applies what it is told, so a run that corrupts the animation list is caught by the next mutation in the same run. * fix(studio): decide a uniform resize in pixels, not in scale A free corner drag whose two axes happened to land within 0.01 of each other was committed as one `scale` value for both, and gave back a box shorter than the one dropped — 326x213 became 326x211. The threshold was a fixed amount of scale. That is invisible on a 40px box and two pixels of height on a 408px one, and the question was never about scale: it is only ever whether using one value for both axes would move an edge. So it asks that, in pixels, against the axis the collapse would distort. Found by a geometry sweep added alongside: 120 runs over the routes a resize can take, six rotations from none to 180 degrees, and four drops from near-zero to an aspect flip, each checking the committed scale or size reproduces the RENDERED box the user dropped — and, where the resize reports it owns the drag offset, that the box lands on the drop point too. Six runs failed before this change, all of them the near-uniform shrink, at every rotation including none. Rotation was the suspect and turned out to be innocent. * refactor(studio): split the resize sweeps into named steps for the audit gate * test(studio): pin which tween a resize edits when the element has several A composition animates the same property more than once — a scale-in early, a scale-out late — and the one the user means is the one under the playhead. Editing the wrong one changes a moment they are not looking at and leaves the moment they are looking at unchanged, which reads as "the resize did nothing". Six playheads across two scale tweens, including both sides of the midpoint between them and a time past the end of both. Verified against a stubbed selection that always takes the first tween: three of the six fail. * fix(studio): only claim the drop point on the route that settles it Review caught the inverse of the fault above it. The three returns that report `ownsDragOffset` hardcoded `true`, and they are reached by the size-tween route too — a real, non-hold size tween with no scale group. That route never captures the element, so the finalize step no-ops, nothing writes the position, and the caller withholds an offset it would otherwise have forwarded. The release frame looks right because the live DOM was already settled; the persisted state reverts on the next seek. Fixed the same way the fault above it was: the finalize step reports whether it settled the drop point rather than the caller assuming from where it was called. It answers false when it is not the scale route, false when it cannot measure, and TRUE when the box is already on the point with nothing to write — forwarding an offset on top of that would move it off. The geometry sweep accepted this silently, and the reviewer said why: its live pose starts at the drop, which is where the gesture leaves it, so a route that moves nothing trivially "lands" there. Each route now declares whether it settles the drop point and the sweep holds it to that, which fails on 24 of the 120 runs with the old hardcoded `true`.