Remove viewport estimation from VirtualizingStackPanel #13169
Merged
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?
This PR removes the viewport estimation in
VirtualizingStackPanel
, which could be wrong, especially in nested scroll viewers.What is the current behavior?
When inside a
ScrollContentPresenter
,VirtualizingStackPanel.EstimateViewport()
tries to estimate its viewport when it doesn't have one (it just got attached to the visual tree), and can incorrectly estimate a very large viewport, effectively realizing all items. See #10968 (comment) or the added unit test for a simple reproduction.What is the updated/expected behavior with this PR?
With this PR, we don't try to estimate the parent viewport at all. If we don't have one, it's an empty viewport.
While we can refine the estimation to better handle scrollable containers, I don't think it's worth it. Let me explain:
EstimateViewport
, we're in a new measure pass: the arrange pass hasn't run yet, which means the parents bounds might change right after the estimation. In this case, we might still realize totally unneeded items, even with a better estimate.VirtualizingStackPanel
gets attached to an already arranged visual tree. An empty viewport means we're doing nothing1, and that is cheap. We can wait to have a proper viewport to realize the items properly.Pinging @grokys to ensure there's nothing obvious I'm missing here.
A unit test has been added.
Fixed issues
Footnotes
well, not exactly, the first item is always realized even with an empty viewport, but that's another issue. ↩