Bug 46856 - UWP phone Navigate to exist page still very slow.
Summary: UWP phone Navigate to exist page still very slow.
Alias: None
Product: Forms
Classification: Xamarin
Component: Windows ()
Version: 2.3.3
Hardware: PC Windows
: Normal normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2016-11-12 15:29 UTC by Mike
Modified: 2017-06-19 17:26 UTC (History)
5 users (show)

Tags: uwp, navigation, performance, ac
Is this bug a regression?: ---
Last known good build:

Sample file (364.03 KB, application/x-rar)
2016-12-07 17:49 UTC, Mike

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 for Bug 46856 on Developer Community or GitHub if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: Developer Community HTML or GitHub Markdown
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:

Description Mike 2016-11-12 15:29:28 UTC
No matter use:

Navigation.push(ExistPage)  or Navigation.pop();
Master.Detail = ExistPage;
App.MainWindow = ExistPage;

All very slow on UWP.

I think something will reset every time navigate to exist page.  Like ListView will reload.

Also I found the ScrollViewer will reset to 0(if the exist page last time you scroll to 100 and navigate back you will find you lost the last position).

Maybe that's why it will slow.

PS: it's more obvious in Real phone.(phone use ARM CPU).  Like Lumia 640.   PC CPU is powerful, so no need to worry.
Comment 1 Mike 2016-11-12 15:56:00 UTC
Now every time switch page just like freeze the app a while.
Comment 2 Mike 2016-12-02 06:02:12 UTC
I thought it's a ListView problem before, but looks like it's not.  I put some viewcontent to ScrollViewer, still that kind of slow.

Also every time no matter you navigate to exists page or back to the last page, the ScrollViewer will reset the scroll position. (Listview scroll too).
Comment 3 Mike 2016-12-07 17:00:58 UTC
Team, I thought Xamarin so slow on UWP, or my phone (Lumia640XL) really really has a low hardware configuration. But, after I tried the TabbedPage, Wow....That's really really fast than before.  Why ?  Why?   guys, I highly recommend replace every other page logic with something you guys use in TabbedPage, include:

App.MainPage = page;
MasterDetailPage.Details = page;

because these pages navigate all very slow, also I confirmed what I said before:"something will reset when navigate to exist page: https://bugzilla.xamarin.com/show_bug.cgi?id=48682". Looks like that will really turn all slow, after use TabbedPage, ScrollViewer not lost the position which I scrolled last time.

I will upload a sample for you guys understand what's the different between TabbedPage and other pages.
Comment 4 Mike 2016-12-07 17:48:49 UTC
I made 4 sample for this:

1.First demo just show you after simply switch the root page App.MainPage = exists page, it's slow and ScrollViever will reset the position.
2.Master Details change current detail page also same.
3.Navigation page push or pop also same.(but when pop page, will not lost scrollviewer, but still slow)
4.Tabbed Page no that kind of problem, fixed all.(only the first time load the page slow, of course it would be more better if we could let that more fast or initialized before when we create the page, not when navigating. In my app I will initalized all page when App startup)

Please test it on real phone, I was tested it on Lumia 640XL,(on PC you can't feel the speed), in Lumia it will take 4-5 seconds around, but Tabbed page only take 1 secound around.(when second time navigate, first time still slow even I'm already initialized the page)
Other pages which I was not used yet, please test it yourself.

That's a big performance problem in this half year since I've been use Xamarin, I hope that will be on team high priority. Thanks.(also I have a feeling on the 3 navigation way have a memory leak too when every time switch or navigate exists page)
Comment 5 Mike 2016-12-07 17:49:29 UTC
Created attachment 18813 [details]
Sample file
Comment 6 Samantha Houts [MSFT] 2017-03-16 01:00:02 UTC
Comment 7 David Ortinau [MSFT] 2017-06-16 21:44:08 UTC
We've determined this PR isn't going to work to resolve this issue. I'm moving this issue back to confirmed and asking Paul to revisit it.
Comment 8 Mike 2017-06-17 05:14:08 UTC
@David Ortinau , Please tell me why do you think that PR isn't going to work to resolve this issue? I've already use it in my project, It's fast and fine. It's decide ,vote and confirmed by Xamarin Forums.

Comment 9 Paul DiPietro [MSFT] 2017-06-19 15:43:47 UTC
The PR has a number of issues which primarily involve it only being implemented on one of the platforms. This will be revisited.

That said, looking into the reproduction again, this issue is not helped by some of the layouts which are unncessarily complex in places, such as this small snippet:

                <ScrollView  Margin="6,20,0,0" >
                    <Label Text="switch and navigate very slow on exist page"/>

                <Button x:Name="btn" Text="Back"/>

            <ScrollView  VerticalOptions="FillAndExpand">
                <StackLayout x:Name="lvList">


Nesting so many layouts such as a StackLayout inside of a Grid for an inexplicable reason is going to cause less than optimal performance on a $30-40 device such as the Lumia 640. The cell templates themselves are a bit large in places, too. 

This is not to say that we cannot make improvements; we'll look to revisit the ideas in the PR in the future. This issue will be closed for now and the aforementioned thread can be left for reference.
Comment 10 Mike 2017-06-19 15:55:06 UTC
@Paul DiPietro , No. I don't agree with you.  The problem itselft is caused because the UWP of Xamarin project always dispose the old page when navigate to other page, and when navigate back it will initialize the all thing in the already exist page.

It's a very bad design it self.  I put a fix PR before but denied by your team:

After that , they want me add a extension for this, that's why I put RetainsRenderer for this. You could see this in :


Or you could see some detail about it in the PR:https://github.com/xamarin/Xamarin.Forms/pull/647

the problem not about the Grid or StackLayout in here, It's about the page reload exist page, I very disappointed you not get this. Also about the other platform, I think that's the job your team need to do (I've already waited for this for half year more).

[Don't request the user use the simple layout always, improve your ugly design first].
Comment 11 Chris King 2017-06-19 16:35:40 UTC
Assigned to you because bug you were last to resolve bug before it was re-opened.
Comment 12 David Ortinau [MSFT] 2017-06-19 17:03:16 UTC

If that PR works for you, then you have a workaround. 

We are not at present comfortable accepting the PR in its current state for reasons noted on the PR, those Paul mentioned, and those on the forum thread. We have to think of the entire platform and how a PR like this impacts the broader Xamarin.Forms project, and not just your application.

You are absolutely welcome to disagree, and to fork and run with your implementation. We welcome your PRs and your willingness to work with us. If you want the PR sped along, please work with us to do the work. If you are wanting us to do the work and we agree it should be done, then it will be prioritized among the rest of our workload. That prioritization will not match your own. Jason said as much on the forum, and I continue to echo that statement.

Please revisit our code of conduct. https://open.xamarin.com/code-of-conduct 

I understand you are frustrated with these answers, but I caution you you keep frustration from becoming hostile.

Since we have a PR that addresses this issue but cannot be accepted without changes, and you don't want us to close this ticket and track the progress via the PR, I will mark this ticket confirmed. 

If you update the PR and we merge it, we can then close this issue. Otherwise, this issue will remain in our work queue until we are able to get to it.
Comment 13 Mike 2017-06-19 17:26:10 UTC
Hi David,

I'm working fine and fast with this PR, but problem is I can't always update the code, because the Xamarin.Forms source code change too much. I think you guys should take some developers to track and merge this code ASAP, It's very painfull for me because the code need to keep update and keep older.

Actually I don't sure other platform has this kind of problem or not, If not I hope your team just merge it without add some kind of Extension or Attachment class (I was requested do it like that).
I also find out a lot of problem in UWP was connect with this BUG, If you guys not update it soon, It's more painfull in future, because It will connected with some other codes.

Yes, thank you, don't close it please, until merge. you could still hold this PR, until maybe Windows phone dead, but I don't recommend that!

I also need to say, My local Github code already can't continue with the newer Xamarin.Form source code,  every day I'm in the pain only hope you guys merge it soon.