RadJumpList breaks page transiton

[ManniAT]

Hi,

I have (had) a pivot page using some (SL) listboxes.
The page has a "fade" transition.

Everything works fine.
Then I changed the SL listbox to a RadJumpList.

The effects:
    a.) blank (dark) screen - than the page just appears (no fade)
    b.) navigating away has no transition (no fade effect) also
It just takes some time (for whatever) and the page goes away.

I can improve the loading by adding a timer in "page load" which fires the jumplist binding about 500ms later.
If I do it to fast (timer value to small) it doesn't help - else I get a fade (with an empty listbox) and later the data items appear.
Still no "fade out" on that page.

It seems as if the start animation waits till the JumpList is bound - which unfortunately takes pretty long (>1sec) for about 500 Items grouped by their first character.
Of course I tried to use "IsAsyncBalanceEnabled" - but the effect is not useable.
If I start to scroll (what user would do for sure) the line "drop in one after one".
And if I scroll fast - I sit in front of an empty listbox which takes about 2 and more seconds till the lines fill.

Anyhow - even if I could somehow optimize my code (selectors) - there is still the "no fade out" which is pretty bad,
since there is a delay where nothing happens - so it looks as if the user didn't "hit ok" followed by an imideate disappear of the page.

And to remember - everything works fine if I use the default listbox - OK except one thing - the animation start seems to wait for the data to be bound - so my "progress bar" never shows up.
Before I had page transitions I got a progress bar showing up followed by a filled listbox.

Regards
Manfred

[Deyan]

Hello Manfred,

Thanks for contacting us.

We have made some investigations based on your observations and have been able to reproduce the behavior that you describe.

In general there are a couple of important points to mention which are relevant when comparing RadJumpList to the Silverlight Toolkit's LongListSelector.

The LongListSelector control uses ContentPresenter instances as container objects whereas the RadJumpList control uses ContentControl instances for the same purpose. The ContentPresenter is considerably lighter when it comes to visualising content with a template but it does not support styles. That is why we decided to use ContentControls in RadDataBoundListBox and in RadJumpList respectively. For instance, the selection mechanism uses this to change the forecolor of the selected item by updating the visual state of the selected container which is defined in its default style. This extended functionality of ContentControl brings its performance hit as well.

Since we think good performance is very important on the phone, we decided to extend our UI virtualization engine that supports RadJumpList so that it supports both ContentControl and ContentPresenter based containers. In this way we will make sure that we address similar performance hits and also preserve the existing functionality that is provided by the fact that we use ContentControl based visual containers.

We hope that we will be able to provide this functionality for Q2 2011.

You can write back anytime you have further questions or need assistance.

Kind regards,
Deyan
the Telerik team

[ManniAT]

Thank you for this information Deyan,

I guess there are two problems - one is performance - and the other is (I guess) related to page transition.

From what I see (I didn't check the source code) the transition animation waits till the "page" has built (displayed) then it starts (resumes?) the animation. Or at least it behaves like this.

With the (now I know why) faster Long.... I fall in this timeframe - so I see some animation.

And (against my above writing) it looks like - header fades in - listbox entries appear a bit later.
So there the animation starts "correct" and brings the result I want.

By the way - I have still no explanation why "fade away" doesn't animate.

Anyhow - since I also have memory issues using a form (pivot) with two instances of JumpList (every open / close adds about 5 MB Memory usage in my Main Pivot) I changed the design to use a RadWindow with one instance of a JumpList - the List is much faster in this case - and instead of providing two lists I use the (real cool and fast) feature of switching the grouping on demand.

Just to be precise - three things changed - one instance instead of two - RadWindow instead of navigation to a pivot page and no "Sort Criteria" on JumpList - this was used in the second instance which no longer exists.

Also strange (positive in this case) - I have no longer loading time problems (about 100ms on first load less on subsequent loads) and the only thing I have to "fix" is the group picker loading animation - which has to be faster for my use.
The rest works like a charm. I (of course) also gave it a try with the Long... - but there I have to rebind the data for different groupings - which means holding two list (with different structure) while I can simple change the group description with the JumpList.
If "Sorting" was the problem - I'll simple provide sorted data - and if (I didn't try till now) filtering is as responsible as grouping I finally got a perfect solution.

To explain it a little - the user chooses an Item from a list - checks the result in a different list - chooses another item - and so forth.
What I already have is grouping the list by first character or category.
What I'll also need (I'll try to use the JumpList filter for this) is switching between "all items" and "favorite items" (favorite is a boolean property on each item).

Regards and thank you for the fast (and precise) information
Manfred

[Deyan]

Hi ManniAT,

Thanks for writing back and for the details.

In fact, optimizing the performance of a WP7 Silverlight application is a real challange. If you have to coope with large amounts of data and still have good user experience - you have to be really careful and make sure that you avoid doing unnecessary processing.

We still will continue researching different possibilities for squeezing maximum performance out of RadDataBoundListBox/RadJumpList so you can stay tuned for further news on this front.

Do not hesitate to get back to us if you have further feedback to share with us or need assistance.

Thanks for your time.

Best wishes,
Deyan
the Telerik team