Closed Sergtek closed 1 year ago
It will probably work fine if you remove outer VerticalStackLayout.
It will probably work fine if you remove outer VerticalStackLayout.
I've tried it but the problem still occurs. I would bet more that it is a problem with the recycling of CollectionView elements since the more items the ItemSource has and the more controls the DataTemplate has the slower the startup is because it probably proceeds to render all the controls of all the items of the CollectionView.
Ok, I had a similar issue, but caused by the stack layout - it allows collectionView to grow infinitely, and therefore render all the items. It was closed as not a bug, unfortunately :(
Probably this one is different though, if it didn't help for you.
Btw, you don't need an outer ScrollLayout either, CollectionView is already scrollable.
Ok, I had a similar issue, but caused by the stack layout - it allows collectionView to grow infinitely, and therefore render all the items. It was closed as not a bug, unfortunately :(
Probably this one is different though, if it didn't help for you.
Btw, you don't need an outer ScrollLayout either, CollectionView is already scrollable.
As far as I see something similar has happened to me, since removing the ScrollView works correctly, probably what you said is that with the ScrollView allowed the CollectionView to grow infinitely until all its elements are rendered. This doesn't seem very appropriate, does it make sense for the CollectionView to grow infinitely when it is inside a ScrollView, can this thread be closed, or is it a bug?
I think the important thing is here is that it works well in Forms. Then it should also work in .NET MAUI as far as I'm concerned :)
Additional note: The CollectionView only grows infinitely when it's inside a ScrollView or VerticalStackLayout. With the rest of the Layouts it does not happen.
I try https://github.com/nacompllo/MauiCollectionView on android emulator. It takes about 1 minute to initialize.
Hello, I was looking what was I missing because the same code run in a blink of an eye on Xamarin Forms but on MAUI.... A simple collection of 3000 items takes 5 seconds to render on a real device while it was something like 0.1/0.2 on Xamarin Forms.
And don't even try to scroll on a ListView/CollectionView of more than 100 items : you definitively see the caching strategy in action : it freezes and jerks each time a new line appears on screen...
ouh i hope there is coming a fix soon. ListView and CollectionView is so incredible slowly.
For tests i run my Views only in a Grid without anything around, use only "10" items and have just the same issue as the Thread Owner. I cant scroll without lag time from 1-2 seconds. Xamarin was so smooth <3
Cant understand why this isnt fixed right now.
Do you have an ETA on this issue? I'm struggling to use my app especially on low spec devices due to this issue.
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
I am having the same issue with 1k items it is taking well over 10 minutes to load on an emulator and my datatemplate is simple
the collectionview is housed in a MAUI toolkit Popup here is what the xaml would look like the contentView is a seperate file that is shared between a contacts page and a new message popup where the issue occurs.
<toolkit:Popup>
<Grid>
<ContentView>
<Grid>
<Grid>
<CollectionView>
<DataTemplate>
<Grid>
<Label>
<Label>
</Grid>
</DataTemplate>
</CollectionView>
</Grid>
</Grid>
</ContentView>
</Grid>
</toolkit:Popup>
If i do not house this collectionview in a popup page then it renders quickly
@nacompllo I'm looking at your sample:
https://github.com/nacompllo/MauiCollectionView
It puts dotnet_bot.svg
3 times for each row. This is a 672x832 image squashed into a tiny <ImageButton/>
.
Can you use a different image, maybe one that is sized appropriately for the space inside a button?
I'll remove the images and profile what I see for now.
@PureWeen @hartez would you know why the above example seems like it might be rendering every row in the CollectionView
? Should it only be doing this for the elements visible? Is CollectionView
"virtualized"?
The app start times for me on a Pixel 5 are:
.NET 6: 16s412ms
.NET 7: 14s642ms
There does appear to be a goldmine of things to optimize in here: collectionview.zip
(The trace ending in 637 is .NET 6, and 947 is .NET 7)
@jonathanpeppers this hierarchy feels problematic
<ScrollView>
<VerticalStackLayout>
<CollectionView
If you just put the CollectionView
as the root of the page, change VSL to a `Grid', or set the height of the CV does it perform better?
The thing about the VSL is that it has infinite height so it has no idea what height to give the CollectionView
. The StackLayout in MAUI works different that FORMS but it's now consistent with UWP.
If you put a CV inside a VSL the VSL basically tells the RecyclerView hey you have infinite space to exist in so the RecyclerView says cool I'm gong to create all my rows.
From the XAML
it seems like the ScrollView
was added to compensate for the behavior of the VSL?
I have the same problem. CollectionView takes more than 4 to 6 minutes to load 200 (GParams.GVDiplayLoadLimit) items. Items are displayed on two rows. No images loaded. Below is my XAML and Code to load data into the CollectionView ItemsSource
<Grid Grid.Row="1" VerticalOptions="FillAndExpand">
<Frame x:Name="FrameLocations">
<!--<Label Text="Locations" />-->
<CollectionView BackgroundColor="LightSkyBlue"
ItemTemplate="{StaticResource DataTemplateLOC}"
ItemsSource="{Binding AllSitesDv}"
SelectedItem="{Binding CurrentSiteDv}"
Style="{StaticResource ColWithEV}" />
</Frame>
<Frame x:Name="FrameObservations">
<!--<Label Text="Observations" />-->
<CollectionView ItemTemplate="{StaticResource DatatemplateOBS}"
ItemsSource="{Binding AllObservationsDv}"
Style="{StaticResource ColWithEV}" />
</Frame>
</Grid>
private async Task DisplaySites()
{
ObservableCollection AllSitesDv;
Task var1 = Task.Run(() =>
{
AllSitesDv.Clear();
if (AllSites.Count <= 0) { return; } //handle zero records
if (AllSites.Count < GParams.GVDiplayLoadLimit)
{
for (int i = 0; i < AllSites.Count; i++)
{
AllSitesDv.Add(AllSites[i]);
}
return;
}
for (int i = 0; i < GParams.GVDiplayLoadLimit; i++)
{
AllSitesDv.Add(AllSites[i]);
}
});
await var1;
}
@PureWeen Is it possible to change VSL behavior back to being limited?... Or at least throw some error in such cases? I think there are at least 10 different issues logged here related to that.
Frankly, I feel like StackLayouts are very confusing in MAUI and mostly useless, as we have to use Grid in most cases (StackLayout was confusing as hell in XF as well, but for different reasons).
@jonathanpeppers this hierarchy feels problematic
<ScrollView> <VerticalStackLayout> <CollectionView
@nacompllo I basically just removed the outer two layouts and the app looked the same to me.
The app starts in 822ms on a Pixel 5, that is a huge difference down from 16 seconds!
Or at least throw some error in such cases?
@Dreamescaper are you aware of anything other frameworks do like this? WPF?
If you wrapped any "virtualizing" panel in a ScrollView
, I'm pretty sure it would do the same thing in WPF...
Right now the only idea I can think of is if CollectionView
logged a warning at the console, but that doesn't feel very visible -- no one would see it.
@jonathanpeppers I'm not talking about ScrollView here, but about VerticalStackLayout. I haven't ever worked with WPF, but I did work with XF, where StackLayout didn't grow infinitely.
Right I'm referring to WPF, because it is the OG XAML UI framework that has all the same concepts
You do not need a StackLayout to reproduce the slow collectionview in my example above just a collectionview housed inside a popup page from MAUI Community Toolkit behaves the same as if it were housed in a Stacklayout even though there is none in XAML.
@jonathanpeppers At least this change should be properly documented. Multiple issues were closed as "not-a-bug" (e.g. #5442, #4115, #4107, I assume that this one will be closed as well), and in all of them it was mentioned that this changed should be documented. But I haven't found any mentions of that neither in StackLayout documentation, nor in XF migration guide.
@PureWeen Is it possible to change VSL behavior back to being limited?... Or at least throw some error in such cases? I think there are at least 10 different issues logged here related to that.
Frankly, I feel like StackLayouts are very confusing in MAUI and mostly useless, as we have to use Grid in most cases (StackLayout was confusing as hell in XF as well, but for different reasons).
Is it only confusing because it grows infinitely? Or do you have a different use case.
StackLayout was confusing as hell in XF as well, but for different reasons
This is basically what we're wanting to fix inside .NET MAUI
At this point in MAUI, StackLayouts work in a much more deterministic way. The controls are all allowed to be the size they want to be and XF doesn't try to just guess which leads to StackLayout was confusing as hell in XF as well
If the user doesn't provide guidelines for how to size elements we can't guess what size those elements should be. That's why a Grid
is recommended for cases like this.
I realize it's a pain moving from XF but the end result is more logical and more performant when you use the correct layouts for your scenario.
For example, you could put a CollectionView with 15 items in a VSL and it renders the whole thing which a user might want.
Or at least throw some error in such cases?
I could see a more helpful warning if a CollectionView grows to a given size.
@PureWeen
Is it only confusing because it grows infinitely? Or do you have a different use case.
That is one use case, and yes - it is quite confusing. I wouldn't expect ScrollView, for instance, to be completely unusable inside of VSL. Second one is that VerticalOptions are ignored for VSL (and HorizontalOptions for HSL). I get that Expands were confusing, but personally I would expect that an item with HorizontalOptions="End" would be displayed, well, in the end.
I just feel that StackLayouts in MAUI are applicable for the simplest cases only, while in XF it was one of the most used controls. And if you think that is the proper way to go - ok, that's fine. But the lack of communication and documentation (apart from comments in github issues) regarding this change is, again, confusing.
For example, you could put a CollectionView with 15 items in a VSL and it renders the whole thing which a user might want.
I heavily doubt that, especially since the user won't even be able to scroll those 15 items in VSL.
@LennoxP90 Does it help if you set HeightRequest explicitly for CollectionView to some value?
I tried what you suggested and it worked, but I would like the collectionview take up the visual space it is housed in. I am guessing when it comes to a Popup page the height must be infinite even though the visual constraints do not extend past what is shown on screen
Below i have set the height request to 200
the problem is that collectionview is shared between a full tab page and a popup page with different styling, so I didn't have to have duplicate code, and if i set the height on the popup page it will not be full height in the tab page which only shows the collectionview. I guess the simple solution is not share code
Btw it still is not super fast around a second to load instead of minutes, but this same code worked flawlessly in XF
@LennoxP90 how are you creating your popup page?
if( !bPopupShown )
{
//DL - 2022/09/09 - Setup PopupPage
ContactsPopup = new ContactsPopupPage();
ContactsPopup.Closed += ContactsPopup_Closed;
ContactsPopup.Opened += ContactsPopup_Opened;
//ContactsPopup.CanBeDismissedByTappingOutsideOfPopup = false;
Shell.Current.CurrentPage.ShowPopup( ContactsPopup );
}
my issue is more likely and issue with the community toolkit but it could stem from something that changed in MAUI because all of this worked fine in XF
What does the markup in your ContactsPopup look like?
Here is the popup page
<toolkit:Popup xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
xmlns:toolkit="http://schemas.microsoft.com/dotnet/2022/maui/toolkit"
xmlns:controls="clr-namespace:WiFiMessenger.Controls"
xmlns:viewmodels="clr-namespace:WiFiMessenger.ViewModels"
xmlns:models="clr-namespace:WiFiMessenger.Data.Models;assembly=ClientBusinessLogic"
xmlns:wfm="clr-namespace:WiFiMessenger"
x:DataType="viewmodels:ConversationsViewModel"
x:Class="WiFiMessenger.Pages.ContactsPopupPage">
<!--<controls:PopUpPageBase.Animation>
<animations:ScaleAnimation PositionIn="Right"
PositionOut="Right"
DurationIn="300"
DurationOut="300"
EasingIn="SinOut"
EasingOut="SinIn"
HasBackgroundAnimation="False"/>
</controls:PopUpPageBase.Animation>-->
<Grid Margin="25,75,25,80"
RowDefinitions="40, *, 50"
BackgroundColor="#2D2D2D">
<Label Text="Create Conversation"
FontSize="Default"
Margin="12"
TextColor="White"
HorizontalTextAlignment="Center"
HorizontalOptions="Center"
Grid.Row="0"/>
<controls:ContactSelect Grid.Row="1"/>
<Button Margin="60,24"
x:Name="cancelButton"
Text="CANCEL"
FontSize="Medium"
CornerRadius="15"
HeightRequest="40"
Grid.Row="2"
BackgroundColor="#C10100"
Command="{Binding CancelButtonCommand}"/>
</Grid>
</toolkit:Popup>
Here is the shared ContactSelect view (The tab control is just a grid and each tab is a grid base class)
<?xml version="1.0" encoding="UTF-8"?>
<ContentView xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
xmlns:controls="clr-namespace:WiFiMessenger.Controls"
xmlns:models="clr-namespace:WiFiMessenger.Data.Models;assembly=ClientBusinessLogic"
xmlns:wfm="clr-namespace:WiFiMessenger"
x:Class="WiFiMessenger.Controls.ContactSelect">
<ContentView.Content>
<controls:TabControl DefaultSelectedIndex="0"
VerticalOptions="Fill"
HorizontalOptions="FillAndExpand"
SelectedColor="#ff7070"
UnselectedColor="#C10100"
RowDefinitions="40, *">
<controls:TabButtons ColumnSpacing="4"
controls:TabControl.Row="0"
ColumnDefinitions="50*,50*"
RowDefinitions="35">
<controls:TabButton Text="CONTACTS"
controls:TabButtons.Column="0"
FontSize="Small"
TextColor="White" >
<Button.Triggers>
<DataTrigger TargetType="Button" Binding="{Binding GroupsTabVisible, Source={x:Static wfm:App.DatabaseHelper}}" Value="False">
<Setter Property="controls:TabControl.ColumnSpan" Value="2" />
</DataTrigger>
<DataTrigger TargetType="Button" Binding="{Binding GroupsTabVisible, Source={x:Static wfm:App.DatabaseHelper}}" Value="True">
<Setter Property="controls:TabControl.ColumnSpan" Value="1" />
</DataTrigger>
</Button.Triggers>
</controls:TabButton>
<controls:TabButton Text="GROUPS"
controls:TabButtons.Column="1"
FontSize="Small"
TextColor="White"
IsVisible="{Binding GroupsTabVisible, Source={x:Static wfm:App.DatabaseHelper}}"/>
</controls:TabButtons>
<controls:Tab x:Name="ContactsTab"
controls:TabControl.Row="1"
IsVisible="False"
RowDefinitions="25,*"
VerticalOptions="FillAndExpand">
<!-- DL - 2022/08/10 - 21023 - WFMC: add a filter to the contacts screen -->
<SearchBar x:Name="ContactsSearch"
controls:Tab.Row="0"
Placeholder="Search Contacts..."
TextChanged="ContactsSearch_TextChanged"
TextColor="White"
PlaceholderColor="LightGray"
BackgroundColor="DimGray"
CancelButtonColor="#C10100"/>
<CollectionView x:Name="ContactsListView"
ItemsSource="{Binding ContactList, Source={x:Static wfm:App.DatabaseHelper}}"
BackgroundColor="Teal"
controls:Tab.Row="1"
HeightRequest="200">
<CollectionView.ItemTemplate>
<DataTemplate>
<Grid Margin="0,0,0,5"
RowDefinitions="40, 1"
ColumnDefinitions="Auto, *"
Padding="5"
ColumnSpacing="10"
x:DataType="models:ContactModel">
<Label Text="{Binding DisplayName}"
FontSize="Medium"
LineBreakMode="TailTruncation"
FontAttributes="Bold"
Grid.Row="0"
Grid.Column="0"/>
<Label Text="{Binding Description}"
TextColor="Gray"
FontSize="Small"
Grid.Row="0"
Grid.Column="1"/>
<Grid Grid.ColumnSpan="2" Grid.Row="1" BackgroundColor="White" Opacity=".11"/>
</Grid>
</DataTemplate>
</CollectionView.ItemTemplate>
</CollectionView>
</controls:Tab>
<controls:Tab x:Name="GroupsTab"
IsVisible="True"
controls:TabControl.Row="1"
RowDefinitions="25,*">
<!-- DL - 2022/08/10 - 21023 - WFMC: add a filter to the contacts screen -->
<SearchBar x:Name="GroupsSearch"
controls:Tab.Row="0"
Placeholder="Search Groups..."
TextChanged="GroupsSearch_TextChanged"
TextColor="White"
PlaceholderColor="Gray"
BackgroundColor="Transparent"
CancelButtonColor="#C10100"/>
<CollectionView x:Name="GroupsListView"
ItemsSource="{Binding GroupList, Source={x:Static wfm:App.DatabaseHelper}}"
controls:Tab.Row="1">
<CollectionView.ItemTemplate>
<DataTemplate>
<Grid Margin="0,0,0,5"
RowDefinitions="Auto, 1"
ColumnDefinitions="Auto, *"
Padding="5"
ColumnSpacing="10"
x:DataType="models:ContactModel">
<Label Text="{Binding DisplayName}"
FontSize="Medium"
LineBreakMode="TailTruncation"
FontAttributes="Bold"
Grid.Row="0"
Grid.Column="0"/>
<Label Text="{Binding Description}"
TextColor="Gray"
FontSize="Small"
Grid.Row="0"
Grid.Column="1"/>
<Grid Grid.ColumnSpan="2" Grid.Row="1" BackgroundColor="White" Opacity=".11"/>
</Grid>
</DataTemplate>
</CollectionView.ItemTemplate>
</CollectionView>
</controls:Tab>
</controls:TabControl>
</ContentView.Content>
</ContentView>
I also encountered this performance problem. Is there a repair plan?
Can this be solved or explained better in the documentation. We are converting a Xamarin application and it is far to slow to release to clients with the CollectionView scrolling in Maui. Xamarin worked fine across devices, Maui is very slow and not acceptable.
Xamarin <3 Maui yuk
@StephenWin can you share a sample project with this issue? I would like to profile it, or if you have a .speedscope
file to share?
We have instructions on profiling here: https://aka.ms/profile-maui
The solution earlier in this thread, was to remove extra views around CollectionView
: https://github.com/dotnet/maui/issues/6317#issuecomment-1248127141
Which caused it to realize every row.
Thank you for this but I will try to find the cause myself later today first if I can.
The CollectionView is just in a plain
But I must say it is not just one CollectionView that performs badly on Maui, just simple ContentPage changes are slow on Android and the whole application on a capable phone seems sluggish and performs worse than the Xamarin version. In fact the Xamarin version is much better even on a slow phone on Android.
Between the numerous bugs / differences between windows and Android I find myself having to work around or code around Maui really is looking to be a poor substitute for Xamarin.
From: Jonathan Peppers @.> Sent: 02 November 2022 12:03 To: dotnet/maui @.> Cc: Stephen Winstanley @.>; Mention @.> Subject: Re: [dotnet/maui] .NET MAUI RC1 - CollectionView extremely slow (Issue #6317)
@StephenWinhttps://github.com/StephenWin can you share a sample project with this issue? I would like to profile it, or if you have a .speedscope file to share?
We have instructions on profiling here: https://aka.ms/profile-maui
The solution earlier in this thread, was to remove extra views around CollectionView: #6317 (comment)https://github.com/dotnet/maui/issues/6317#issuecomment-1248127141
Which caused it to realize every row.
— Reply to this email directly, view it on GitHubhttps://github.com/dotnet/maui/issues/6317#issuecomment-1300225996, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABL2OKSL3G25J4I3OIU7F5LWGJJ6DANCNFSM5T4IMEQQ. You are receiving this because you were mentioned.Message ID: @.**@.>>
Are you testing a Release
build?
Not yet so far only development, is it vastly faster in release ?
From: Jonathan Peppers @.> Sent: 02 November 2022 14:52 To: dotnet/maui @.> Cc: Stephen Winstanley @.>; Mention @.> Subject: Re: [dotnet/maui] .NET MAUI RC1 - CollectionView extremely slow (Issue #6317)
Are you testing a Release build?
— Reply to this email directly, view it on GitHubhttps://github.com/dotnet/maui/issues/6317#issuecomment-1300586748, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABL2OKTHBZ7LHRJGV5DTZHTWGJ523ANCNFSM5T4IMEQQ. You are receiving this because you were mentioned.Message ID: @.**@.>>
Yes, that is why there is a such thing as Release
mode.
Debug
also has UseInterpreter=true
set by default, which enables C# hot reload.
Haha yes of course, I will try this.
However I must say that Xamarin was faster even debugging and much easier with far less gotchas and bugs than Maui. Xamarin was made for easy application development and with Maui this seems to not be the case which is a shame.
From: Jonathan Peppers @.> Sent: 02 November 2022 15:07 To: dotnet/maui @.> Cc: Stephen Winstanley @.>; Mention @.> Subject: Re: [dotnet/maui] .NET MAUI RC1 - CollectionView extremely slow (Issue #6317)
Yes, that is why there is a such thing as Release mode.
Debug also has UseInterpreter=true set by default, which enables C# hot reload.
— Reply to this email directly, view it on GitHubhttps://github.com/dotnet/maui/issues/6317#issuecomment-1300624438, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABL2OKXMMVESAHGFW3RC4FLWGJ7QZANCNFSM5T4IMEQQ. You are receiving this because you were mentioned.Message ID: @.**@.>>
After optimising the DataTemplates for the CollectionView and putting in release mode it will be acceptable. It would seem to be more fussy about what Xaml to use to get the speed in the templates.
What is still very slow is the page changes on Android. With Xamarin there was a nice zoom in, zoom out effect when navigating forwards and backwards that was very fast. With Maui there is a scroll left / right effect that seems to pause half way a lot of the time and looks very poor. Even in release mode this is very noticeable.
Thank you for your help today
From: Jonathan Peppers @.> Sent: 02 November 2022 15:07 To: dotnet/maui @.> Cc: Stephen Winstanley @.>; Mention @.> Subject: Re: [dotnet/maui] .NET MAUI RC1 - CollectionView extremely slow (Issue #6317)
Yes, that is why there is a such thing as Release mode.
Debug also has UseInterpreter=true set by default, which enables C# hot reload.
— Reply to this email directly, view it on GitHubhttps://github.com/dotnet/maui/issues/6317#issuecomment-1300624438, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABL2OKXMMVESAHGFW3RC4FLWGJ7QZANCNFSM5T4IMEQQ. You are receiving this because you were mentioned.Message ID: @.**@.>>
Sure, can you share a sample project of this? and file a new issue?
This seems like a different topic than this issue.
Sure, can you share a sample project of this? and file a new issue?
This seems like a different topic than this issue.
@jonathanpeppers there is a sample project on this issue, that might be the same issue - https://github.com/dotnet/maui/issues/7494
I was having the same issue. Wrapping the CollectionView in a ScrollView fixed it for me.
I also started using .AddRange() instead of .Add() when adding new items to the collection (https://github.com/jamesmontemagno/mvvm-helpers)
@StephenWin can you share a sample project with this issue? I would like to profile it, or if you have a
.speedscope
file to share?We have instructions on profiling here: https://aka.ms/profile-maui
The solution earlier in this thread, was to remove extra views around
CollectionView
: #6317 (comment)Which caused it to realize every row.
This cannot be a solution. What if one needs the extra views around the CollectionView?
@andy-shindey I think you can use CollectionView.Header and CollectionView.Footer
In release build, items load fast, but xamarin forms work fastest..
I am facing the same issue. StackLayout
, VerticalLayout
affect the CollectionView
and ListView
performance. There is a delay to load a list of 224 items. I tried to optimize the DataTemplate
design but the CollectionView
performance still very poor in android compare to iOS. In xamarin form it was performing great
Btw, you don't need an outer ScrollLayout either, CollectionView is already scrollable.
Huh, seriously? I had to use a stacklayout and a scrollview to make that work
Description
Doing some tests with the CollectionView I have realized that the control is extremely slow in .NET Maui, I have added a DataTemplate with several elements to simulate a scenario as close to reality (production environment) and I have realized that something is not It is working well since the more items the ObservableCollection has linked to the ItemsSource and the more items the CollectionView has to render, the slower the application starts, the only thing that occurs to me is that the CollectionView recycling system is not working correctly and render all the CollectionView items at the same time, I have created an identical repository in Xamarin.Forms with 9999 items in the CollectionView and everything works fast and well, however in .NET Maui the same case but only with 300 items takes 2:20 minutes in start the app.
When you go to do the tests, all you have to do is go to the MainPageViewModel class and in the constructor there is a loop that is in charge of initializing the ObservableCollection linked to the CollectionView, by default it is configured in 300 elements, which more or less will do that the app takes about 2:20 seconds to start completely, even when it starts after that time there is a little lag if you try to scroll in the CollectionView until a few seconds pass and the performance stabilizes. I recommend lowering that number to 50 or 100 for faster testing in .NET Maui. In the Xamarin.Forms repository it is set to 9999 items and the performance is perfect and fast, probably because the Xamarin.Forms recycling system works fine.
Loop image:
I leave the 2 GitHub repositories in case you need to do tests:
.Net Maui: https://github.com/nacompllo/MauiCollectionView
Xamarin.Forms: https://github.com/nacompllo/XamarinCollectionView
Steps to Reproduce
Download the attached repository and follow the instructions detailed above.
Version with bug
Release Candidate 1 (current)
Last version that worked well
Unknown/Other
Affected platforms
Android, I was not able test on other platforms
Affected platform versions
Android 10
Did you find any workaround?
No response
Relevant log output
No response