Smoke-test report: dragging the window edge to resize was sluggish.
Profiling showed each WindowResized event triggered ~170 entity
mutations across all 52 cards: full Sprite regeneration via
card_sprite plus despawn_related on each card's CardLabel children
followed by a fresh with_children spawn — and WindowResized fires per
pixel of drag, multiplying the cost.
Three fixes layered together:
1. resize_cards_in_place is a new function the resize handler calls
instead of sync_cards. It mutates Sprite.custom_size, the card's
Transform.translation, and existing CardLabel TextFont.font_size
directly — no Sprite replacement, no despawn_related, no child
rebuild. update_card_entity stays unchanged for non-resize callers
(deals, moves, flips, settings changes) so the full-repaint path
they need is preserved.
2. collect_resize_events reads events.read().last() and stashes only
the latest size into a ResizeThrottle resource each frame, so
multiple WindowResized events in one frame collapse to one apply.
3. snap_cards_on_window_resize is gated by a 50ms throttle
(RESIZE_THROTTLE_SECS): work runs at ~20 Hz during a sustained
drag instead of ~120 Hz. When the user stops resizing the next
frame flushes the final pending size, so the steady state always
matches the released window dimensions. should_apply_resize is a
pure helper unit-tested for the threshold-and-baseline contract.
apply_stock_empty_indicator gained a QueryFilter generic so the new
resize handler can pass a Without<CardEntity> filter — the resize
query already takes &mut Sprite on cards, so the indicator query had
to disjoin to avoid aliasing.
Five new tests pin the contract: should_apply_resize at three
threshold boundaries, plus integration tests that fire WindowResized
and assert no CardLabel entities were despawned and that
TextFont.font_size shrinks in place.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
funman300
1719fdada0