AvaloniaUI
Horizontal Misalignment of Cells During Vertical Scrolling with Non-Realized First Column
Description When the first column is not realized, an incorrect horizontal position of the cells occurs during vertical scrolling. This issue is demonstrated in the attached video.
Steps to Reproduce
- Open the TreeDataGrid.
- Ensure that the first column is not realized.
- Scroll vertically through the grid.
Expected Behavior The horizontal position of the cells should remain correct and aligned during vertical scrolling.
Actual Behavior The horizontal position of the cells is incorrect and misaligned when scrolling vertically.
Environment TreeDataGrid Version: 11.0.10 Avalonia Version: 11.0.10 Operating System: Windows 11
Additional Information See the attached videos demonstrating the issue:
https://github.com/AvaloniaUI/Avalonia.Controls.TreeDataGrid/assets/50872233/7b7f8f9b-a614-442d-af20-a09b0aedee21
https://github.com/AvaloniaUI/Avalonia.Controls.TreeDataGrid/assets/50872233/85d89a95-d786-4179-96ad-4e54a41eb3bf
P. S. I'm sorry if I didn't explain it clearly, my English is not perfect
I researched this problem and found that the function GetOrEstimateAnchorElementForViewport() in RealizedStackElements works incorrectly when the 'for' loop inside it does not call return. If you cache the parameters 'u' and 'i', this problem will be fixed, but it is the wrong approach because it breaks the tests. https://github.com/00jeser/Avalonia.Controls.TreeDataGrid/commit/4e2a8c95694d2c9714980c7890bf92c7ec4b05ce
A similar bug (probably having the same root cause) has been raised by a user of my own application ImageFan Reloaded, with a video attached to this comment exposing the issue.
@00jeser Any update on this? Perhaps there's a workaround without your code change? This issue is a deal breaker for me being able to use this control.
We have fixed this issue in our own fork, by abandoning the "Or Estimate" side of the GetOrEstimateAnchorElementForViewport routine. Instead, we are simply calculating the actual widths of columns without estimation. We are presently working on fixing the same problem for the height of rows. After that, we will have to see if AUTO sizing needs further work.
I don't think estimates are of any value in achieving correct "smooth scrolling" behavior, because the nature of an estimate is that it is known to be incorrect by an unknown margin. In your recordings, you are seeing the error of the estimated column width being drawn and never fixed, even after the cells have been realized in the wrong place.
@busitech could you share the fix for GetOrEstimateAnchorElementForViewport ?
https://github.com/AvaloniaUI/Avalonia/pull/16168
these changes in the main avalonia repo, may well be relevant to this issue.
@danwalmsley Yes, I will share a patch file with you. The Avalonia project classes are not used that much in the TreeDataGrid project, which has its own implementation of virtualization.
@danwalmsley Here is the way we fixed the issue in our project, which is suitable for our use cases.
In a nutshell, our changes remove the use of estimates from the scrolling logic in both directions. This avoids the misaligned cells when horizontally scrolling, and allows us to smoothly page in more records when vertically scrolling. Previously, when the user picked up the gripper or thumb and moved it drastically, or used a trackpad to scroll fast, it confused the control.
For horizontal scrolling, we decided to defer to the columns to represent their own width, and assume there won't be millions of columns (this would not perform well otherwise).
For vertical scrolling, we calculate which row should be visible based on the grid scroll position of the thumb. This assumes there could be millions of rows (and will perform well in that case).
If a use case comes up where there are millions of columns, then the approach we took for rows could be used instead.
Also included is a fix so that right justified labels can be used in TDG cells without being too wide or truncated after a previously cached control is reused.
If you decide to use our patch, let us know if you find a use case they do not support well, or witness any strange behavior.
@danwalmsley In my earlier message, I thought you were an end user of Avalonia looking for a solution, but I just noticed you are @ Avalonia... :joy:
@busitech thank you :) I had a few minutes to test your patch. It seems to work! I will get more time this week and see if I can test it a bit more. I did manage to trigger an exception (invalid size returned from measure), but haven't looked into it yet.