Skip to content

Width-only fast path for vertical list resize (lazy item width) - #521

Open
Spelt wants to merge 1 commit into
MagicFoundation:masterfrom
Spelt:feature/width-only-realign
Open

Spelt wants to merge 1 commit into
MagicFoundation:masterfrom
Spelt:feature/width-only-realign

Conversation

@Spelt

@Spelt Spelt commented Sep 9, 2026

Copy link
Copy Markdown

A live window-resize of a vertical list only changes the content WIDTH: every item Top stays valid, yet DoRealign repositioned all items - on a 24k-item list that is ~100ms of SetBounds per WM_SIZE, freezing the resize. TMainContent.SizeChanged now detects the width-only case and resizes just the visible/preloaded window; the remaining items get their width lazily in FetchContent (EnsureItemWidth, under FDisableAlign so the item SizeChanged cannot cascade into a realign), right before the content builder captures the item bounds. A full DoRealign(0) clears the lazy flag again.

Also completes the preloaded-window bookkeeping from #519 for the insert side: inserting inside the window no longer extends it across the inserted (never prepared) items - the shifted prepared tail is unprepared and the window is clamped to the part before the insertion point, mirroring the DeleteItems bookkeeping. This also keeps the width-only pass bounded to the real window.

A live window-resize of a vertical list only changes the content WIDTH:
every item Top stays valid, yet DoRealign repositioned all items - on a
24k-item list that is ~100ms of SetBounds per WM_SIZE, freezing the
resize. TMainContent.SizeChanged now detects the width-only case and
resizes just the visible/preloaded window; the remaining items get
their width lazily in FetchContent (EnsureItemWidth, under
FDisableAlign so the item SizeChanged cannot cascade into a realign),
right before the content builder captures the item bounds. A full
DoRealign(0) clears the lazy flag again.

Also completes the preloaded-window bookkeeping from MagicFoundation#519 for the
insert side: inserting inside the window no longer extends it across
the inserted (never prepared) items - the shifted prepared tail is
unprepared and the window is clamped to the part before the insertion
point, mirroring the DeleteItems bookkeeping. This also keeps the
width-only pass bounded to the real window.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant