Repository navigation
Conversation
maxkatz6
approved these changes
Oct 25, 2026
MrJul
enabled auto-merge
October 25, 2026 16:28
NuGet packagesThe packages for this pull request have been published (workflow run):
|
izakusilov
deleted the
22192-always-true-condition-in-virtualizingstackpanel
branch
October 25, 2026 20:27
MrJul
pushed a commit
that referenced
this pull request
Nov 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does the pull request do?
Fixes an always-true condition in
VirtualizingStackPanel.RealizeElementsthat caused elements before the anchor element to be recycled even when they are still needed.What is the current behavior?
RealizeElementsdecides whether elements before the anchor can be recycled upfront with:Since
uwas just assignedviewport.anchorU, the condition is always true, so elements before the anchor are always recycled. When the anchor starts after the start of the viewport, the backward pass then has to realize those same elements again from the recycle pool.This is visible e.g. when an item is inserted into the visible range and immediately scrolled into view: every visible container above the new item is cleared, removed from the visual tree and re-prepared, and the items can end up in different containers.
What is the updated/expected behavior with this PR?
Elements before the anchor are only recycled upfront when the anchor starts at or before the start of the viewport, as the comment describes. Otherwise they are reused by the backward pass, and anything left over is still recycled after it, as before.
To test: insert an item into the visible range of a virtualized list and call
ScrollIntoViewon it. The containers of the visible items before it are kept as they are.How was the solution implemented (if it's not obvious)?
The condition now compares the anchor position against
viewport.viewportUStartinstead ofviewport.anchorU. In the common case (the anchor is the first element that crosses the start of the viewport) the behavior is unchanged.Added
ScrollIntoView_Inserted_Item_Does_Not_Recycle_Elements_Before_It, which fails without the fix. AllAvalonia.Controls.UnitTestspass with the fix.Checklist
Breaking changes
None.
Obsoletions / Deprecations
None.
Fixed issues
Fixes #22192