Skip to content

Remove viewport estimation from VirtualizingStackPanel #13169

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Nov 3, 2023

Conversation

MrJul
Copy link
Member

@MrJul MrJul commented Oct 8, 2023

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:

  • It would involve knowing how each parent control in the hierarchy has arranged its children, reversing the usual roles.
  • The estimation uses the parent bounds. It means a full layout pass (measure + arrange) already occurred previously. When calling 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.
  • This estimation never applies on the first layout pass: nothing has a size yet, so we get an empty viewport. With this PR, this is also the behavior everytime the 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

  1. well, not exactly, the first item is always realized even with an empty viewport, but that's another issue.

@avaloniaui-team
Copy link
Contributor

You can test this PR using the following package version. 11.0.999-cibuild0040555-beta. (feed url: https://nuget-feed-all.avaloniaui.net/v3/index.json) [PRBUILDID]

@maxkatz6 maxkatz6 requested a review from grokys October 8, 2023 23:35
@grokys grokys added this pull request to the merge queue Nov 3, 2023
Merged via the queue into AvaloniaUI:master with commit dca8cd4 Nov 3, 2023
@MrJul MrJul deleted the fix/vsp-viewport-estimate branch November 5, 2023 11:59
@maxkatz6 maxkatz6 added backported-11.0.x backport-candidate-11.0.x Consider this PR for backporting to 11.0 branch and removed backported-11.0.x backport-candidate-11.0.x Consider this PR for backporting to 11.0 branch labels Dec 5, 2023
maxkatz6 pushed a commit that referenced this pull request Dec 5, 2023
* Added failing VirtualizingStackPanel viewport test

* Remove viewport estimation from VirtualizingStackPanel
#Conflicts:
#	tests/Avalonia.Controls.UnitTests/VirtualizingStackPanelTests.cs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Listbox extreme memory usage and low performance when nested and in a tab control
4 participants