Bug 60751 - ListView UWP extremely poor rendering performance when inside a StackLayout
Summary: ListView UWP extremely poor rendering performance when inside a StackLayout
Status: RESOLVED NOT_REPRODUCIBLE
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms ()
Version: 2.5.0
Hardware: Other Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2017-11-18 18:06 UTC by nitemsg
Modified: 2018-01-03 17:09 UTC (History)
3 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
uwp listview problem demo (320.28 KB, application/x-zip-compressed)
2017-11-18 18:06 UTC, nitemsg
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED NOT_REPRODUCIBLE

Description nitemsg 2017-11-18 18:06:27 UTC
Created attachment 25754 [details]
uwp listview problem demo

When u have a ListView that is a child inside a StackLayout then the rendering is extremely slow in UWP, even on a high end PC. You can actually see each row being added/rendered.
Same goes when the contents are scrolled.

But when not inside a StackLayout, the performance is OK. 

Example attached. Check DemoPage.cs in the shared project.
Comment 1 Paul DiPietro [MSFT] 2017-11-18 18:36:01 UTC
Please test against the latest 2.5 stable and report back on whether it makes any difference. I do not experience the issue when running the provided reproduction against that version.
Comment 2 nitemsg 2017-11-18 19:53:38 UTC
Tested it against the latest 2.5.0.91635. The problem still exists.
Comment 3 Paul DiPietro [MSFT] 2017-12-15 17:42:24 UTC
Running the project again to verify the original findings, there is minimal to no rendering of the list when the application loads, and none when scrolling. Ultimately, performance is dependent upon the device or computer's specs much like any other application. Visual rendering of items is not something that is Forms specific and can occur on regular UWP apps as the items are realized. In this case, this appears to simply be rendering working as expected.
Comment 4 nitemsg 2017-12-18 11:31:52 UTC
The difference in performance when the ListView is inside a StackLayout vs when its not, is not XForms specific? Then why in Xamarin.UWP the UI native controls (Windows.UI.Xaml.Controls.ListView, stackpanel etc) perform entirely differently (a LOT better) vs Xamarin.Forms in the exact same hardware ?

Yes, hardware does make a difference, but how is it possible that plain Xamarin.Forms.ListView works great even in a slow tablet, while if using it inside a Xamarin.Forms.StackLayout in the exact same tablet everything get frustratingly slow ? Shouldn't Xamarin.UWP perform just as bad, in the exact same hardware instead of working great ?
Comment 5 Paul DiPietro [MSFT] 2018-01-03 17:09:00 UTC
A stated, no severe drop in performance was noted in this scenario using the reproduction. Without more information about specific hardware or a reproduction which guarantees that the behavior will be exhibited, we cannot move forward with this. Please refile an issue on GitHub with a more clearly defined scenario in terms of hardware setup where this issue may apparently be occurring, but for the time being this will be closed as no further reports of this kind have been made from other users regarding this issue.