GridView is much slower than ListBox/ListView

[f-shake]

Firstly thanksfor this gui library, it is very beautiful.

When I Use Gridview to show thousands of files like file explorer in windows, it has bad performance. The flowwing is my codes:

 <m:GridView     x:Name="lbxGrdFiles" ContextMenu="{StaticResource menu}"
                      PreviewMouseDoubleClick="lvwFiles_PreviewMouseDoubleClick" 
                         ItemsSource="{Binding Path=PagingFiles}" >
                <ListBox.ItemTemplate>
                    <DataTemplate >
                        ...
                    </DataTemplate>
                </ListBox.ItemTemplate>
            </m:GridView>

The app need about ten seconds to load layouts. Thus I have to page Files (120 files/page), but it is still cost about 1s to load.
I use ListView with same ItemsSource, it load quickly that less than 0.5s. These are my codes with ListView:

 <ListView   ItemsSource="{Binding Files}" x:Name="lvwFiles" SelectionMode="Extended"
                    Loaded="lvwFiles_Loaded"  PreviewMouseDoubleClick="lvwFiles_PreviewMouseDoubleClick"  ContextMenu="{StaticResource menu}"   >
                <ListView.ItemContainerStyle >
                    <Style TargetType="ListViewItem">
                        <Setter Property="HorizontalContentAlignment" Value="Stretch" />
                    </Style>
                </ListView.ItemContainerStyle>
                <ListView.ItemTemplate>
                    <DataTemplate>
                    ...
                    </DataTemplate>
                </ListView.ItemTemplate>
            </ListView>

Maybe the GridView has no virtual list? I've tryed to add VirtualizingPanel.IsVirtualizing="True" to xaml, but it doesn't work.

You can see my source here

Is there any way to improve its performence?
thanks.

[f-shake]

I found a solution. The key of low performence is because GridView use WrapPanel which is not a VirtualizingPanel. so I use a Nuget called VirtualizingWrapPanel, then I edit my code like this:

<ListView     x:Name="lbxGrdFiles" ContextMenu="{StaticResource menu}"
                      PreviewMouseDoubleClick="lvwFiles_PreviewMouseDoubleClick" 
                         ItemsSource="{Binding Path=Files}" >
                <ListBox.ItemsPanel>
                    <ItemsPanelTemplate>
                        <wpftk:VirtualizingWrapPanel Orientation="Vertical"/>
                    </ItemsPanelTemplate>
                </ListBox.ItemsPanel>
            </ListView>

now it's as fast as ListView. I Suggest to replace wrappanel in ModernWpf.Controls/ListView/GridView.xaml with VirtualizingWrapPanel, it is open source and should be easy to use its code.

its nuget url is here

[Kinnara]

Confirmed against current 1.x with an exact live regression probe.

I hosted a ModernWpf.Controls.GridView at 400×300 DIPs with 1,000 fixed-size (80×60) templated items, forced layout, and counted generated item containers through ItemContainerGenerator.ContainerFromIndex.

Result before any change: 1,000 / 1,000 containers realized. The probe correctly failed an assertion requiring fewer than 100 viewport-adjacent containers:

GridViewVirtualizesItemsOutsideTheViewport
Failed: expected realizedCount < 100
Actual: 1000

The cause remains the default GridView.xaml WrapPanel. Setting VirtualizingPanel.IsVirtualizing cannot make a non-virtualizing panel generate/recycle containers.

I am leaving this issue open because the safe library fix is not a narrow panel substitution. It requires a repository-owned wrapping VirtualizingPanel that implements WPF's item-generator and scrolling contracts, including recycling, extent estimation, resize/reflow, keyboard/focus bring-into-view, collection mutation, variable-size compatibility, and behavior across net462/net8/net10. Pulling in or copying the suggested third-party package also requires an explicit dependency/licensing/package-shape decision. The current source audits explicitly record native GridView data virtualization as a WPF-platform boundary rather than claiming parity.

The reporter's application-level ItemsPanel workaround remains valid. I removed the temporary failing probe and restored a clean worktree. This issue is confirmed and actionable as a larger feature, but blocked for this narrow repro → fix → PR pass.