Hi,

as my game's gui is nearly finished I'm testing the game more and more on mobile devices. As the game also includes an account management system next to various other things I'll only instantiate and add certain UserControls when needed.

Of course this results in a small delay when opening certain dialogs, meaning the usually smooth opening animations are not or only barely visible. Once they're in memory closing and opening it again looks as expected. You can also notice this small delay on a desktop pc, but naturally a lot less.

Now the question is whether I change it so that these dialogs, which are mostly only rarely needed, are instantiated from the beginning, so the animations would be smooth. They would use up more memory, of course.

So is there a way to check how much memory a UserControl uses at runtime? I could use the TaskManager and just compare the values from before and after opening such a dialog but I presume these values would not be necessarily accurate.

We have an internal profiler that we use here for measuring many things. We have plans to release this tool (with many improvements like a visual tree explorer) in 1.4. The tool will allow you to connect to any instance running in any device and display all the information.

But, this is not coming soon, so yes, I recommend you using standard tools. The memory profiler integrated in XCode is amazing.

In the incoming 1.2.6 we are also improving loading times a bit.

Hey,

I don't know if this might be of any use but as we noticed that as well on our first try working on B&C (my project), those lags.

The way that you might use to overcome that is that, when you open the previous menu, you load as well this menu, even if the changes for it to be loaded in the end as small.

For example, let's say that you have an Option menu that then can lead to the Account management, you would load/create the account management at the moment you open/create the option menu.
I am not sure of the impact it would have on the opening of the option menu. but if you create if beforehand and create the Account management when opening it, it might allow you to have smooth transitions. Maybe at the cost of a bit of memory though.

From what we gathered, those spikes in the profiler seem to happen when you create a NoesisGuiPanel.

I don't know if this might help.
If it does, great! If not, sorry for the message.

Hi and thanks for your replies.

@jsantos: I'll give XCode's memory profiler a try next week.

@Erio: I was thinking about something very similar but I find it very difficult to say this dialog (also its own UserControl) should be loaded because it's related to another one, but that doesn't mean the user will ever use it.

For instance the account management (AM) consists of different 8 dialogs:

- Overview
- EULA
- Registration (those two are related indeed)
- Login
- Forgot Username
- Forgot Password
- Activation
- Change Userdetails

Of course I could instantiate all other dialogs if the user opens up the AM overview but that would consume some memory and right now I don't know how much.

But if the user opens the "Login" dialog does that mean I should also instantiate the "Forgot Username" and "Forgot Password" dialog just because he can access them from there? What are the chances that he will navigate to them? And what about the activation? Has he already activated his account?

As I said I find it hard to predict which dialogs will be opened by the user. The easiest way would be to just instantiate all dialogs and if the memory usage is low enough I would just do that. If not I can leave it as is or I have to make some 'assumptions' on what the user is most likely going to do.

I was also thinking of implementing a two way step. So when I call GuiDisplayService.Show() to open a dialog that's not already instantiated, I could first instantiate it, wait for the IsLoaded event (if there is one) to fire and then open the dialog. So you would have a small 'hiccup' but the opening animation would be smooth again, at least so I hope.

And don't worry, I really appreciate that you were writing back.

When loading new UserControl dialogs there are 3 processes involved that may lead to some spikes:

1) Loading UserControl associated dialog
Whenever a UserControl is instantiated and initialized (added to the UI tree), its associated xaml must be loaded from disk and all elements defined created. This shouldn't take to much time.

2) Initialization and Layout of UserControl's subtree
All elements must be initialized (styles and templates applied, and bindings solved). Then elements must be layout so they can know where and how to be rendered. We are making huge improvements on this step for 1.2.6 version. In this step, animations started at Loaded time are also registered and started.

3) Update render thread and render
Visual nodes must be created in the render thread for each visual element of the dialog. Also geometries and new brushes must be created to render the visual nodes. If you reuse brushes and don't use very complex geometries this step only depends on the number of visual elements contained by the dialog. If this step takes to much time, animations started in previous step may be finished when next frame is ticked, so a workaround may be to delay a bit the fade in animation.

My recommendation here is to cache in memory only big panels that are used a lot, and load dynamically the rest. Is our job to speed up loading/initialization/update times enough to allow small panels to be created dynamically without spikes.

Thanks for your explanations.

Are these improvements already implemented in v1.2.6beta? If so I could check whether it has minimized this issue.

Yes, they are included in the b3 we delivered today.

Excellent!