Listbox – ScrollViewer performance improvement for Mango and how it impacts your existing application?

 We have heard this over and over, having a smooth scrolling ListBox on Windows Phone is a core scenario. We received feedback on WP7 that the listbox scrolling experience for applications is not at par with the native applications on the phone, like Outlook. We absorbed all the feedback and optimized this experience as can be seen in Scott’s key note demo at MIX11 @ 01:02:25. 

Interactivity -  response to touch, the sense of the ListBox(ScrollViewer) responding to your touch almost instantaneously keeps your apps’ end user gripped to the application and was among the first things we wanted to improve. To do this we had to move the listening of the touch gestures to a separate thread. This meant an architecture level change for how we listened to the gestures and the response to these gestures for scrolling animations. We deftly handled various threads, one each for input (Input thread), animations (Compositor thread), and creating new items (UI thread). 

We made this sweetness available for all the applications, irrespective of the version of your app. As soon as the end user upgrades the phone to Mango update all the existing applications on their phone will get this new improved smooth scrolling experience. 

What does this mean for application authors?? Developers have to do NOTHING to get these improvements. 

Unless… performance improvements don’t just come without removing some extra work that was happening. We had to make changes to reduce the load on the UI thread by reducing the update frequency of a few lower priority events and properties. 

So we have the following low impact minor changes: 


7.0 App on WP7

7.0 and 7.1 App on Mango

Updating all ScrollViewer properties on the UI thread when scrolling.

Happens as soon as the properties change

Happens only when

a. Finger is lifted or

b. Drags/pans/flicks move more than 1/4th of the screen in any direction

If this impacts your app, follow the mitigation*

Raising Manipulation Delta events on UI thread when dragging inside ScrollViewer

Will be available to be handled by the elements in the ScrollViewer

Will be swallowed by the ScrollViewer, as they are on the input thread, This is part of the performance improvement where we don’t raise unnecessary series of events to optimize the core scrolling experience

If this impacts your app, follow the mitigation*


What is your responsibility as App Developer?

 Test your app on the latest Mango tools as soon as possible. Look for subtle impact of this change on your application. 

There is an extremely low probability that your application is *negatively* impacted by this change.  


 If you find yourself in a position where your app is doing something we did not anticipate or is being impacted by a scenario where we picked performance over functionality, then the following the mitigation routes are available.

Option #1: Opt-out of this improvement.

Not recommended, and not preferred option, available only for special apps that cannot work without the events/properties being updated like the WP7 version.  

In that case:

  1. Upgrade your application to 7.1
  2. Opt out of this improvement by using the following property on ScrollViewer:


<ListBox ItemsSource="{Binding Items}" ScrollViewer.ManipulationMode ="Control" Height="652" Canvas.Top="80">

If it says “Do Not Use” then above link is not updated yet.


Following will be edited and published at the above link:


public enum ManipulationMode


            // Controls can handle their own interactivity and all listbox properties/events/methods available



            // Default, System takes over optimizing the interactivity experience, limiting the frequency and availability of properties/events/methods




        //Lets you select the Gesture interactivity for the scrollviewer/listbox and should be set once

        public ManipulationMode ManipulationMode { get; set; }





The ManipulationMode has already been set and cannot be changed after OnApplyTemplate ()


Option #2: Modify the application code to work around the changed behavior

 If your app is doing something that is taking a dependency for the properties/events to be updated as soon as they happen then we would strongly recommend to remove those dependencies. 

Top example that falls in this bucket is if you have a TextBlock within a ScrollViewer with HorizontalScrolling Enabled and this TextBlock is part of a Panorama Item. You will see a slight delay in pano item swap when you do a slow horizontal drag within the TextBlock.

 This is due to Panorama wanting to listen the gestures of all its child controls, but in this case the child control’s gesture is on a separate thread that doesn’t bubble up the manipulation deltas. For this particular case, just turn off the horizontal scrolling for the TextBlock’s ScrollViewer. It is against the Metro UI guidelines anyway. 

Build a community for changes like these, blog about the corner cases you run into, platform will do the same.


Where this change doesn’t apply ?


If your application is not using the Silverlight ListBox and/or ScrollViewer, you will not get the benefits of this change directly.  

Example, if you are using the existing version of the Silverlight Toolkit LongListSelector you will not see this improvement after the Mango update directly. In that case, you will need to get a newer version of the controls that have been re-written to take advantage of the improvements. Update you application to use the newer controls and then you will see the improvements.


Looking forward to feedback and comments.


Thanks and let the “buttery” smooth scrolling make your end user slip into paying you more for your app !


Silverlight Mobile Performance Team.

Comments (8)

  1. Ade A says:

    What about if you are using ItemsControl?

  2. Jeff Wilcox says:

    @Ade A,

    You'll be fine in most situations – just make sure that your ItemsControl template, or the parent of the control, is a ScrollViewer. ScrollViewer is where the magic happens.

  3. Ade A says:

    @Jeff Wilcox, cool thanks for the reply

  4. ROY BEAN says:

    Posted here (did not appear when posted, maybe will later)…/listbox-scrollviewer-performance-improvement-for-mango-and-how-it-impacts-your-existing-application.aspx

    This is 100% broken in mango's xde…/scrolling-so-smooth-like-the-butter-on-a-muffin-how-to-animate-the-horizontal-verticaloffset-properties-of-a-scrollviewer.aspx

    (that is a convenient sample to start any tests you may want to do)

    Nothing moves, for one (it must actually change the y offset for this to be seen).  For two, a button (at coor 100, 100) tap can activate a textbox (say) at 100, 500, or more likely dead space if nothing is at the bogus coors.  I think

    you underestimate the breakage this is causing.  This code is useful to move controls into view that are beyond the bottom of the scrollviewer's view, so the SIP does not scroll these into view (for one, for two, it makes a nice scroll-to-new-position animation).

    JW: Is your blog back up yet?

  5. @Roy Bean, great feedback. Thanks ! Will look more into the scenario you mentioned.

    Can you also outline which marketplace apps(if any) are using this ?

    If you make the ManipulationMode = Control, it will still work ?



  6. ROY BEAN says:…/

    is even more boiled down.  I've looked at this for about 10 minutes and … it's broken.  At least in xde 7.1 beta.  Something that basic/core should not have been.

    Simple example, take TheScrollViewer manually down a ways, then try this:


  7. @Roy Bean, give me a couple of days to try it out on latest Mango bits.


  8. @RB: I tried it on latest mango build on device(device access is not public, I am part of SLM team) and it works fine as expected. May be a beta bug, dint get a chance to try it on Beta emulator. But the scenario you outlined is supposed to work fine. Here is the WP7.1 version of phone sample.…/

Skip to main content