RadDataBoundListBox goes Mango in terms of scrolling performance (video included)

Back in the days when the first WP7 developer devices were distributed to all enthusiastic developers it became clear that the out-of-the-box scrolling performance delivered by the ListBox control from the toolbox is not satisfying at all. In fact, having some richer data templates and UI virtualization all in one made the control almost unusable which forced many developers to either give up UI virtualization or simply reduce the contents of their templates to boost the scrolling performance and thus improve the end-user experience. Although the Performance Team @ Microsoft have released some nice and helpful hints on how to improve scrolling performance (http://blogs.msdn.com/b/slmperf/archive/2010/10/06/silverlight-for-windows-phone-7-listbox-scroll-performance.aspx), the results at the end of the day weren't that impressive.

These circumstances made us start researching different possibilities to build a lighter and faster listbox control: RadDataBoundListBox. We decided to take a different UI virtualization approach in terms of not relying on layout passes to perform the UI virtualization logic (opposite to the approach in the standard ListBox control where a VirtualizingStackPanel is used) and in this way we managed to deliver significant improvements in terms of performance and responsiveness.

Eventually the phone guys at Microsoft paid attention to what developers were saying about these performance issues and announced that some upgrades will be introduced which will basically make the ListBox’ scrolling performance as smooth as on the native OS implementation (the one you see on the Marketplace app for instance). In a nutshell: a new thread has been introduced in the WP7 OS which basically handles manipulation events and performs the scrolling without constantly interfering with the UI thread but after certain time intervals. This consequently makes scrolling and UI virtualization two independent processes thus leaving enough time for both UI thread to do what it has to and for the Input thread to scroll. The result, compared to what we previously had, is simply marvelous.

Having all these facts on the table was completely enough for us to draw the line and understand that RadDataBoundListBox, in its current state, will NOT perform good enough to compete with what already comes as a standard from Microsoft. Although we have tons of features that the SDK ListBox doesn’t, not being responsive enough wouldn’t make sense to many of you who opt for a third party component. That is why we decided to see what we can do to make use of the new Input thread and try to refresh RadDataBoundListBox so that it delivers more again.

Optimistic enough, we thought that the new Input thread will be something that we, as developers, will be able to utilize on a given control. Later, however, we realized that this nice feature is available only for the ScrollViewer component (via the ManipulationMode property). So, in order to be able to make use of it, we simply had to use it as our items panel for RadDataBoundListBox and put all visual containers there. And this is actually what we did. With some trickery and omitting some great amounts of code (mostly related to our previous scrolling mechanism) we ended up having a nicely revamped RadDataBoundListBox which still successfully outperforms the native one due to its different UI virtualization approach. See for yourself: