Different performance when minimizing and maximizing Tile versus switching between tiles

[Jeff Machamer]

We have a nested RadTileView that is showing a difference in behavior depending on whether or not we minimize a containing RadFluidContentControl (LargeContent->Content) or just switch to a different content control.  When we minimize it, it hangs and takes 3 or 4 seconds to display the Content of the other 5 Fluid Content Controls, the same happens when we attempt to re-maximize it.  If we instead choose to maximize a Fluid Content control that is currently displaying it's small content, the switch is almost instantaneous.

I've verified that we have no code running in the RadFluidContentControl_StateChanged event during the minimize, so there doesn't appear to be anything on our side causing it to go so slow.

We removed the animation from the containing TileView control to make sure that wasn't the source of the problem.

We have also noticed that during the minimize operation, the memory usage appears to spike significantly, but it does not happen when we maximize a small content item to exchange the current large content item.

So I guess my question is, what is different between minimizing a large to content and switching out the large by clicking on the small.  is there anyway to make the minimization work similarly?  Currently if the user doesn't know how to switch between large views the application is much less usable due to the wait times.

Not all of our controls have this problem, just the more complex controls.  So my assumption is that something is being "cleaned up" in once case but not the other?

Thanks,

Jeff

[Zarko]

Hi Jeff Machamer,

 Yes, there's a difference between restoring an maximized item and maximizing an minimized item. In the first case all your RadTileViewItems change their state and their content (largeContent -> content and smallContent -> content), but in the second only the previously maximized item and the newly maximized one change their content(largeContent->smallContent and smallContent->largeContent). So in the first case if you have 10 RadTileViewItems and all of them have some heavy control inside their restored content (like a chart or a gridview) when you restore the maximized item you'll have to create not 2 (like in the second case) but 10 grids or charts and that's where the delay comes from. You can try to remove the transition effects from the RadFluidContentControls and the animations from the RadTileView and see if this helps with the performance:

<telerik:RadFluidContentControl Transition="{x:Null}" ... >

and 

<telerik:RadTileView IsItemsAnimationEnabled="False" ... >

You can also disable the restoring of the maximized item by setting the MaximizeMode property of the RadTileView to "One".
If you need further assistance feel free to ask.

Kind regards,
Zarko
the Telerik team