Open jairbubbles opened 3 years ago
Looks like it's already logged https://github.com/KirillOsenkov/MSBuildStructuredLog/issues/21
And I have a pretty recent (the latest?) .NET Framework version installed (528372).
Yes, this is #21, the workaround is to uncheck this box: https://github.com/KirillOsenkov/MSBuildStructuredLog/issues/21#issuecomment-705112738
BTW thanks for the repro steps, I tried to reproduce and couldn't on my machine. This is highly sensitive to screen DPI, window size, timing of input events, so really hard to find a reliable repro that works across machines. So the bug may still be there or it may be fixed.
Hummm... I still do reproduce it even if I disable the tree virtualisation.
If I attach the debugger I still see the VirtualizingStackPanel
in the stack trace:
> PresentationCore.dll!System.Windows.UIElement.Arrange(System.Windows.Rect finalRect) Inconnu
PresentationFramework.dll!System.Windows.Controls.Grid.ArrangeOverride(System.Windows.Size arrangeSize) Inconnu
PresentationFramework.dll!System.Windows.FrameworkElement.ArrangeCore(System.Windows.Rect finalRect) Inconnu
PresentationCore.dll!System.Windows.UIElement.Arrange(System.Windows.Rect finalRect) Inconnu
PresentationFramework.dll!System.Windows.Controls.Control.ArrangeOverride(System.Windows.Size arrangeBounds) Inconnu
PresentationFramework.dll!System.Windows.Controls.TreeViewItem.ArrangeOverride(System.Windows.Size arrangeSize) Inconnu
PresentationFramework.dll!System.Windows.FrameworkElement.ArrangeCore(System.Windows.Rect finalRect) Inconnu
PresentationCore.dll!System.Windows.UIElement.Arrange(System.Windows.Rect finalRect) Inconnu
PresentationFramework.dll!System.Windows.Controls.VirtualizingStackPanel.ArrangeOtherItemsInExtendedViewport(bool isHorizontal, System.Windows.UIElement child, System.Windows.Size childDesiredSize, double arrangeLength, int index, ref System.Windows.Rect rcChild, ref System.Windows.Size previousChildSize, ref System.Windows.Point previousChildOffset, ref int previousChildItemIndex) Inconnu
PresentationFramework.dll!System.Windows.Controls.VirtualizingStackPanel.ArrangeOverride(System.Windows.Size arrangeSize) Inconnu
I noticed a long delay yesterday while clicking around on search results. I think it occurred when I clicked an item which was one of many siblings in the tree. If I see it again I'll get a trace.
yes, if you have a long list and not using virtualization, the long delay is expected and by design (just lots of layout work that needs to happen)
@KirillOsenkov It is possible that the left tree control (filter) still have virtualization even if the checkbox is unticked and that's the one which is faulty in my case?
I'll look at the code source when I have free time
Oh interesting, it might be possible indeed, need to check
I can confirm that this is the other tree which is responsible for the freeze. If I disable the virtualization on "resultsList" by removing:
VirtualizingPanel.IsVirtualizing="True"
VirtualizingPanel.VirtualizationMode="Recycling"
I no longer have the issue.
Although they're both hangs, this is not really the same as #21 - they have different root causes. To avoid polluting #21, I recommend moving the discussion back here.
The new hang is occurring with the latest .NET updates (that fixed the hangs in #21). Neither @KirillOsenkov nor I can repro it, but I think it's very sensitive to the exact height of the "resultsList" TreeView and the data it displays, and to the exact sequence of scrolling operations; we just haven't stumbled on the right combination. The .stf trace @jairbubbles attached to #21 should help, but I'm still tinkering. @anton-zaicev - can you attach an .stf trace for your case, to confirm that it's the same issue?
Note that this is really an issue in .NET/WPF; there's nothing wrong with Kirill's app. I've asked @KirillOsenkov to open an issue in the internal .NET database, which will justify spending time and effort to diagnose and fix the problem in a .NET servicing update.
I've just made a change for the resultsList
to respect the virtualization setting:
https://github.com/KirillOsenkov/MSBuildStructuredLog/commit/4b307e49dcf171f054239db07f6c9dbb01b36fd0
At least as a workaround you can now turn off the virtualization checkbox on the startup screen to get unblocked: https://github.com/KirillOsenkov/MSBuildStructuredLog/issues/21#issuecomment-705112738
@SamBent, here is my .stf trace: scrollTrace.zip
@SamBent You might have missed it in the other thread but when compiling locally and run with .NET Core 3.1.9 I can't reproduce it. Maybe it doesn't contain the fix that created that new issue?
The two STF traces both show hangs when using MouseWheelDown to scroll forward from a position that is very near, but not quite at, the end of the data. Which means they're probably hitting the same root-cause. But they're different in that one (from @jairbubbles) has "tidy" heights for the viewport and the ListViewItems - 936, 17.6, +2.4 for non-leaves - while the other (from @anton-zaicev) has "messy" heights - 546.857142857143, 17.1428571428571. It probably doesn't matter, but I'm curious if anyone can explain this?
My guess is that the "resultsList" TreeView has UseLayoutRounding=true, and that both users have high-DPI monitors (or enabled DPI scaling), one at 125% yielding an effective pixel size of 100/125 = 0.8, the other at 175% yielding an effective pixel size of 100/175 = .571428571428571. The trace doesn't record either UseLayoutRounding or effective pixel size so I can't confirm my guess. Can you?
@SamBent, yes, I have 175% scale. MainWindow has UseLayoutRounding=true.
@jairbubbles @anton-zaicev if you email me at my first name dot last name at microsoft, I'll e-mail you instructions on how to test the fix. @SamBent was able to reproduce and produced a fix that needs to be tested before they'll allow us to check it in.
OK great news! I was able to reproduce the bug and validate the fix.
Here's the video:
I had also validated the fix and can confirm that the bug is fixed. @SamBent, what is the planned date of release for this fix?
The fix is in the pipeline of review/approval/packaging/testing for inclusion in a .NET servicing update. If no problems arise, it should appear early in 2021. I'll post back to this thread when that happens.
@SamBent, are there any news about planned release date?
Thanks for the reminder.
The fix was released in the .NET Update Preview on Jan 26, and in the .NET Update on Feb 9. The former is available for download, the latter is part of the monthly Windows Update payload. (The KB number depends on which OS version you're running.)
I haven't seen any new reports of hangs for a couple of months now, so I'll consider this issue resolved. Thanks again everyone.
I think we had found regress - same bug after recent update, can you re-check that? PresentationFramework.dll - version 4.8.4360.0
Could you please upload PresentationFramework.dll here?
Here it is. PresentationFramework.zip
Hmm, I have the exact same version of the .dll, but I haven't noticed any hangs. I'll keep a close eye on it.
Any more details about the hang that you can share?
@anton-zaicev any chance that you could record another scrollTrace.stf like you did the last time? https://github.com/KirillOsenkov/MSBuildStructuredLog/issues/407#issuecomment-724201802
https://github.com/KirillOsenkov/MSBuildStructuredLog/issues/21#issuecomment-514701904
Have you tried it with DPI value different from 100%? I'll be back with scroll trace soon.
I usually run with 200% DPI, maybe I should try 125% again (last time we had a repro with 125%)
It is not so easy to repro this time, but behaviour is all the same (DPI > 100%, same scroll actions), this time UseLayoutRounding property is involved. I end up with the same situation (scroll freezing) but only with the UseLayoutRounding="True" for virtualized container, with "False" value there is no any undesired behaviour and it is the temporary fix for now. I had collected scroll trace but not from the MSBuildStructuredLog app, there is same infinite scroll calculations loop as in the previous case. So, how I see, I should move to WPF repo and create issue there? ScrollTrace.zip
yes please open an issue on dotnet/wpf and tag @SamBent
Randomly the UI freezes when selecting an item after doing a search.
When breaking in the code it seems to be stuck while measuring items in the
VirtualizingStackPanel
:I have a fairly good repro:
NB: the text scaling is at 125%