This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 52507 - UI Rendering routine is too slow, here is a fix to make it instant.
Summary: UI Rendering routine is too slow, here is a fix to make it instant.
Status: RESOLVED FIXED
Alias: None
Product: Forms
Classification: Xamarin
Component: Forms (show other bugs)
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2017-02-14 17:10 UTC by Brad Chase
Modified: 2017-03-09 19:07 UTC (History)
5 users (show)

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


Attachments

Description Brad Chase 2017-02-14 17:10:11 UTC
My views take from between 7 seconds and over 10 minutes to render on UWP.  This fix will show how to increase all of those times on UWP to instant:


If you want to replicate an example of how to get the speeds, go into VisualElementTracker and comment out IsInNativeLayout like so:


void MaybeInvalidate()
        {
            //if (Model.IsInNativeLayout)
            //  return;
            var parent = (FrameworkElement)Element.Parent;
            parent?.InvalidateMeasure();
            Element.InvalidateMeasure();
        }


The problem is IsInNativeLayout takes too long when you have a complex tree.  The more controls in a view the worse it gets.
Comment 1 Dominik Weber 2017-02-15 15:15:06 UTC
I have tested your solution and while it really improves the performance A LOT I'm getting "Layout cycle detected" crashes in some views. Maybe we need a better implementation of IsInNativeLayout?
Comment 2 Brad Chase 2017-02-15 17:58:20 UTC
Dominik, that is really strange.  Ours go off without a hitch and we have some really deep views.  We do not use listviews or controls like that because we use our own in house ones.  Can you pinpoint where?  Also I believe that's the only place that checks the isinnativelayout.  I'll check again but I also commented out the contents of the getter on the property to only check itself.  Let me dig into that, can you try to do a little bit of digging to find which control is causing the layout cycle?

Also if you wouldn't mind checking what if you enable the call to the property but only checking the parent rather than the whole tree.  That should remove the layout cycle issue but will slow is down a hair.
Comment 3 Brad Chase 2017-02-15 18:01:11 UTC
Also check the speed increase on just running the app outside of debug being attached.  For Windows just start your app in VS then drop out and search your app name in the startbar.  I find to check the speed that way really shows the difference.
Comment 4 Brad Chase 2017-02-15 18:31:15 UTC

After looking at my previous statement, I meant to say VisualElement NOT VisualElementTracker.  I am not at home so I dont have access to my exact changes which I will post later tonight.  In the mean time...

Your best bet is to comment out IsInNativeLayout like so:

internal bool IsInNativeLayout
		{
			get
			{
				if (_isInNativeLayout)
					return true;
                /*
				Element parent = RealParent;
				while (parent != null)
				{
					var visualElement = parent as VisualElement;
					if (visualElement != null && visualElement.IsInNativeLayout)
						return true;
					parent = parent.RealParent;
				}
                */
				return false;
			}
			set { _isInNativeLayout = value; }
		}

if it is still not working then do this:

		internal bool IsInNativeLayout
		{
			get
			{
				if (_isInNativeLayout)
					return true;

                VisualElement parent = RealParent as VisualElement;
                if (parent != null && parent.IsInNativeLayout)
                    return true;

				return false;
			}
			set { _isInNativeLayout = value; }
		}

but that likely will not change much since the parent already checks and should return with and without the while statement which seems reduntant.


If that doesnt work then do BOTH the tracker and the element.  I believe I have both commented out.
Comment 5 Dominik Weber 2017-02-16 21:56:42 UTC
@Brad Chase in my last test I used Xamarin Forms 2.3.2, now I've tried again with 2.3.4-2 and I don't get layout cycle exceptions anymore. So I guess your fix does work for our app after all ;)

To be clear I do see the performance improvements, maybe it wasn't clear from my last comment: it is like night and day, the difference is hugely amazing. Xamarin please have a look at this! And Brad thank you for finding ;)
Comment 6 Brad Chase 2017-02-16 22:07:33 UTC
@Dominik Weber that is great to hear!  I was just as amazed.  Well more like blown away.  I see the difference now I changed it on the latest nightly 2.3.5-26.  I found UWP for us was completely unusable before this patch and after it is our fastest product :).
Comment 7 Paul DiPietro [MSFT] 2017-02-24 18:56:17 UTC
Please submit changes such as these as pull requests on the Github repo so that they may be properly reviewed, as Bugzilla should be used as a tool to report specific issues. That said, I believe there is a chance for unintended side effects by simply commenting out code in such a fashion.
Comment 8 Brad Chase 2017-02-24 19:23:38 UTC
I dont have time to go put the code in at this moment but I can suggest that you put some time into fixing the rendering.  There is no reason a view should take 10 mins to load.  I can tell you that this fix seems very safe considering you can just search for IsInNativeLayout and remove it completely as its only used on the UWP side AND it is a blocker.

Again I would put the time in, I think the community will give you alot of praise for making 10 minute views and Forms UWP from a completely unusable heap to the fastest version of forms out.  Or you can just mark it at closed, whatever works.
Comment 9 Samantha Houts 2017-03-09 19:07:03 UTC
https://github.com/xamarin/Xamarin.Forms/pull/788 was merged. Should be included in 2.3.5-pre1. Thank you!

Note You need to log in before you can comment on or make changes to this bug.