43db10680e
Previous fix froze ALL of a descendant's clipStack during resize/rotate preview — but that was over-conservative. The first N entries of every subtree-RN's clipStack come from ancestors of the resize/rotate target (unchanged, freeze ✓), but entries from index N onward were pushed by the target itself (when it has clipContent: true) or by its clipContent descendants — those ARE inside the transforming subtree and must scale / rotate alongside the rest of it. Otherwise children appear clipped at the target's pre-transform bounds even though they're rendered at the new bounds. Use rootSnapshot.clipStack.length as the boundary: indices < N stay frozen (ancestor clips), indices >= N get the same scale-from-sourceRect or rotate-around-center transform as the rest of the subtree. The scale factors and rotation parameters match the bounds transforms exactly because every clip pushed inside the subtree was anchored to a node whose bounds are also being transformed. The drag handler stays fully frozen: drag is multi-target with no notion of a single subtree boundary, and the dominant case (single- frame drag without clipContent ancestors in the drag set) is correct under freeze. A precise drag fix would need entry-to-source-id mapping on RenderNode, which is a separate refactor. |
||
|---|---|---|
| .. | ||
| cli | ||
| desktop | ||
| web | ||