You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit ed099ae
Browse filesBrowse the repository at this point in the historyBrowse files
Mavis
authored and
Mavis
committed
fix(compositor): make the zoom-frame growth continuous instead of binary
Follow-up to the original issue #179 fix and the f7c4317 bandaid. The two
earlier commits each made the wrong call: the original swap to [0,0,1,1] in
one step (abrupt padding disappearance), and f7c4317 kept the same switch
but neutralized the shadow and radius to mask the regression (still abrupt
on the padding ring, and now also abruptly loses the frame on zoom engage).
The right behavior: the "zoom frame" (s_dst) grows continuously with the
zoom, from the padded size up to the full frame. At zoom = 1 it's the
padded area. As the zoom ramps up, the frame expands until it hits the
frame edge at zoom = 1 / padding_scale (= frame / padded_size). Past that
the frame stays put and only the source rect keeps shrinking — the GPU
upscales further. The source texture itself is never touched, so full
resolution is preserved all the way; only the mapping changes.
s_radius and the shadow follow s_dst naturally now (s_min_px grows with
the zoom frame), so the f7c4317 gates on those are removed. Result: no
more binary switch anywhere. The padding smoothly fades as the zoom
ramps up, the frame "follows" the zoom, and by the time the content
hits the edges the frame is already at full size — visually consistent.
Single TODO kept, pointing at the still-pending "frame rect" separation:
if you want the shadow and corners to stay anchored at the padded box
while the content overflows (the "window" effect), split the frame rect
from the content rect and apply shadow+corners to the frame alone.
0 commit comments