New IsAsyncBalanceEnabled behaviour in SP1

[Bernhard König]

Hi,

I just checked out the new SP1 release and the new IsAsyncBalanceEnabled behaviour. While in general I like the new apporach more (loading all items that would be visible on screen immediately instead one-by-one) it doesn't perform that well and causes a noticeable delay for the user until he sees the list filling up and also the "gap" that appears after navigating away from the old page and showing the new page is longer now.

To be more precise, of course with the one-by-one approach, the overall time until the complete screen is filled with items is longer, but it's noticeable shorter until the first item appears on screen. I combined this approach with animating each item when it's added to the listbox (kind of a tile animation) so each is animated after it appears on screen. So for the user it seems to perform better because he sees some items on screen earlier and combined with the animation it more looks like a nice, desired effect to the user than real loading time. So the "feeled" waiting time is much shorter as when the user has to stare on a blank screen for about a second.

Another bad side effect for me is that I use the RAdContinuumTransition here. Having a completely filled screen with items increases the fillrate from the beginning, causing the RadContinuumAndSlide animation to be very jaggy (the "sliding" of the content area). That was super smooth before where just the header and the pivot control with an empty list was animated.

So, while not perfect, for my scenario the old way to do it was better. Would it be possible to change the IsAsyncBalanceEnabled property from a bool to an enum and giving me an option that way to set how I would like this function to behave?

It would also be even nicer if an tile-like or selectable/customizable animation would be supported out of the box when new items get added to the listbox during the IsAsyncBalanceEnabled pre-SP1 behaviour.

Thanks :)
Bernhard

[Deyan]

Hi Bernhard,

Thanks for writing back and for the feedback on the new behavior related to using the IsAsyncBalanceEnabled property.

After updating the behavior related to setting this property to true, we haven't noticed any performance and UX issues in our Demos Application. In other words, the RadDataBoundListBox demos which we tested after that deliver pretty much the same user experience. We haven't noticed any performance hits in your application too besides the fact that the animation played on the ItemStateChanged event is no more visible (which is expected behavior). In general, generating 3-5 visual items at once (to fill the viewport) should not be a time consuming operation. Could you please try the same scenario without hooking the ItemStateChanged event and playing the animation. This might decrease the startup time since the event is fired synchronously each time a new visual item is created and thus requires additional time.

Otherwise we will consider your notes on the asynchronous balance approach and will discuss possibilities for improving its behavior. For instance a possible way of handling this functionality would be to fill the viewport synchronously and after that use an async way of realizing items by default (i.e. when the IsAsyncBalanceEnabled is set to false). When the IsAsyncBalanceEnabled is set to true the behavior will be for each item, i.e. without considerations whether the viewport is filled or not.

I hope this is helpful.

Do not hesitate to get back to us in case you have further questions or need assistance.

Kind regards,
Deyan
the Telerik team