If you’ve ever used a ListBox or ScrollViewer control and wanted to implement “infinite scrolling”, great news: in Mango you can easily detect both the end of scroll and compression states.

Infinite scrolling is a nice concept used when the data for a Listbox control is fetched from a server. Many web services let you fetch the data in chunks by specifying a starting location and number of records to retrieve in order to implement paging

A lot of web services are designed for a client to fetch ~40 items. Then, as the end user scrolls to the bottom of the list, client code detects that the end of the scrolling region has been reached (when the list compresses), and then fetches the next 40 odd items from the server.

Obviousy it isn’t a true infinite scrolling list – memory concerns can prop up, but it’ll feel infinite to most users if you implement a reasonable maximum.

How to detect the end of scrolling

On Windows Phone 7.0, the developer community came up with a bunch of hacks that worked in some situations, but we wanted to really offer this functionality in the platform for Mango and feel that it’s a much cleaner implementation as a result. Less hacking required!

So in Mango, throw away your old code – we’ve made this very easy and 100% reliable!

The attached sample shows all the various events that can be hooked to when scrolling on a WP7.1 application.

We addressed this problem by introducing two new VisualStateGroups: HorizontalCompression and VerticalCompression.

The default style for the ScrollViewer does not include these new visual states – if you’re using them in your app, make sure to add a style to the app’s resources to expose these new VisualStateGroups.

Here’s the style:

    <Style TargetType="ScrollViewer">
            <Setter Property="VerticalScrollBarVisibility" Value="Auto"/>
            <Setter Property="HorizontalScrollBarVisibility" Value="Auto"/>
            <Setter Property="Background" Value="Transparent"/>
            <Setter Property="Padding" Value="0"/>
            <Setter Property="BorderThickness" Value="0"/>
            <Setter Property="BorderBrush" Value="Transparent"/>
            <Setter Property="Template">
                <Setter.Value>
                    <ControlTemplate TargetType="ScrollViewer">
                        <Border BorderBrush="{TemplateBinding BorderBrush}" BorderThickness="{TemplateBinding BorderThickness}"
Background="{TemplateBinding Background}">
                            <VisualStateManager.VisualStateGroups>
                                <VisualStateGroup x:Name="ScrollStates">
                                    <VisualStateGroup.Transitions>
                                        <VisualTransition GeneratedDuration="00:00:00.5"/>
                                    </VisualStateGroup.Transitions>
                                    <VisualState x:Name="Scrolling"> <Storyboard>
                                            <DoubleAnimation Storyboard.TargetName="VerticalScrollBar"
Storyboard.TargetProperty="Opacity" To="1" Duration="0"/>
                                            <DoubleAnimation Storyboard.TargetName="HorizontalScrollBar"
Storyboard.TargetProperty="Opacity" To="1" Duration="0"/>
                                        </Storyboard>
                                    </VisualState>
                                    <VisualState x:Name="NotScrolling">
                                    </VisualState>
                                </VisualStateGroup>
                                <VisualStateGroup x:Name="VerticalCompression">
                                    <VisualState x:Name="NoVerticalCompression"/>
                                    <VisualState x:Name="CompressionTop"/>
                                    <VisualState x:Name="CompressionBottom"/>
                                </VisualStateGroup>
                                <VisualStateGroup x:Name="HorizontalCompression">
                                    <VisualState x:Name="NoHorizontalCompression"/>
                                    <VisualState x:Name="CompressionLeft"/>
                                    <VisualState x:Name="CompressionRight"/>
                                </VisualStateGroup>
                            </VisualStateManager.VisualStateGroups>
                            <Grid Margin="{TemplateBinding Padding}">
                                <ScrollContentPresenter x:Name="ScrollContentPresenter" Content="{TemplateBinding Content}"
ContentTemplate="{TemplateBinding ContentTemplate}"/>
                                <ScrollBar x:Name="VerticalScrollBar" IsHitTestVisible="False" Height="Auto" Width="5"
HorizontalAlignment="Right" VerticalAlignment="Stretch" Visibility="{TemplateBinding ComputedVerticalScrollBarVisibility}"
IsTabStop="False" Maximum="{TemplateBinding ScrollableHeight}" Minimum="0" Value="{TemplateBinding VerticalOffset}"
Orientation="Vertical" ViewportSize="{TemplateBinding ViewportHeight}" />
                                <ScrollBar x:Name="HorizontalScrollBar" IsHitTestVisible="False" Width="Auto" Height="5"
HorizontalAlignment="Stretch" VerticalAlignment="Bottom" Visibility="{TemplateBinding ComputedHorizontalScrollBarVisibility}"
IsTabStop="False" Maximum="{TemplateBinding ScrollableWidth}" Minimum="0" Value="{TemplateBinding HorizontalOffset}"
Orientation="Horizontal" ViewportSize="{TemplateBinding ViewportWidth}" />
                            </Grid>
                        </Border>
                    </ControlTemplate>
                </Setter.Value>
            </Setter>
        </Style>

If you compare this with the default style for ScrollViewer, you’ll see it’s really just the original PLUS the two additional VisualStateGroups.

As a reminder, the default style for each control can be found within the System.Windows.xaml file in the following location on a 64-bit machine: C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.1\Design\System.Windows.xaml

So the two additional VisualStateGroups are:

                                <VisualStateGroup x:Name="VerticalCompression">
                                    <VisualState x:Name="NoVerticalCompression"/>
                                    <VisualState x:Name="CompressionTop"/>
                                    <VisualState x:Name="CompressionBottom"/>
                                </VisualStateGroup>
                                <VisualStateGroup x:Name="HorizontalCompression">
                                    <VisualState x:Name="NoHorizontalCompression"/>
                                    <VisualState x:Name="CompressionLeft"/>
                                    <VisualState x:Name="CompressionRight"/>
                                </VisualStateGroup>

The names are self explanatory; “CompressionLeft” means that the compression animation is happening on the ScrollViewer content towards the left side of the viewport.

There are eight combinations coming out of this: top, bottom, left, right, top-left (45 degree angle compression), top-right, bottom-left and bottom-right.

After overriding the default style, you can listen to the CurrentStateChanging event on the corresponding VisualStateGroup element.

To get to the ScrollViewer’s visual state group you need following (building on top of the standard WP7 project template):

private void MainPage_Loaded(objectsender, RoutedEventArgs e)
     {
         if(!App.ViewModel.IsDataLoaded)
         {
             App.ViewModel.LoadData();
         }

         if(alreadyHookedScrollEvents)
             return;

         alreadyHookedScrollEvents = true;
         MainListBox.AddHandler(ListBox.ManipulationCompletedEvent, (EventHandler<ManipulationCompletedEventArgs>)LB_ManipulationCompleted, true);
         sb = (ScrollBar)FindElementRecursive(MainListBox, typeof(ScrollBar));
         sv = (ScrollViewer)FindElementRecursive(MainListBox, typeof(ScrollViewer));

         if(sv != null)
         {
             // Visual States are always on the first child of the control template
            FrameworkElement element = VisualTreeHelper.GetChild(sv, 0) asFrameworkElement;
             if(element != null)
             {
                 VisualStateGroup group = FindVisualState(element, "ScrollStates");
                 if(group != null)
                 {
                     group.CurrentStateChanging += newEventHandler<VisualStateChangedEventArgs>(group_CurrentStateChanging);
                 }
                 VisualStateGroup vgroup = FindVisualState(element, "VerticalCompression");
                 VisualStateGroup hgroup = FindVisualState(element, "HorizontalCompression");
                 if(vgroup != null)
                 {
                     vgroup.CurrentStateChanging += newEventHandler<VisualStateChangedEventArgs>(vgroup_CurrentStateChanging);
                 }
                 if(hgroup != null)
                 {
                     hgroup.CurrentStateChanging += newEventHandler<VisualStateChangedEventArgs>(hgroup_CurrentStateChanging);
                 }
             }
         }          

     }

  private UIElement FindElementRecursive(FrameworkElement parent, Type targetType)
       {
           int childCount = VisualTreeHelper.GetChildrenCount(parent);
           UIElement returnElement = null;
           if (childCount > 0)
           {
               for (int i = 0; i < childCount; i++)
               {
                   Object element = VisualTreeHelper.GetChild(parent, i);
                   if (element.GetType() == targetType)
                   {
                       return element as UIElement;
                   }
                   else
                   {
                       returnElement = FindElementRecursive(VisualTreeHelper.GetChild(parent, i) as FrameworkElement, targetType);
                   }
               }
           }
           return returnElement;
       }

       private VisualStateGroup FindVisualState(FrameworkElement element, string name)
       {
           if (element == null)
               return null;

           IList groups = VisualStateManager.GetVisualStateGroups(element);
           foreach (VisualStateGroup group in groups)
               if (group.Name == name)
                   return group;

           return null;
       }

This will be pretty easy to follow along with if you download and run the sample app. Let us know if this helps you complete your scrolling-related scenarios.

Other important points

• VerticalCompression and HorizontalCompression VisualStateGroups are available ONLY for 7.1
• Both are available ONLY for ManipulationMode = System,
  • What is ManipulationMode = System?
• These groups are not part of the default style, but are available to use.
• You can read about Control Syles and Templates in detail here

Thanks !

SLMPerf

ListBoxVisualStatesDemo.zip

In WP7.0 we had recommended HttpWebRequest over WebClient in our ListBox scrolling post for WP7. Reason for recommending that was, in WP7.0, if the developer created a WebClient request from background thread (any thread actually), the response would always come back to the UIthread. This was causing unexpected heavy processing operations to happen on the UIthread, causing interactivity issues. So we recommended using HttpWebRequests. In HttpWebRequests, the response would come back on the thread where the request originated.

In Mango, 7.1 apps, we fixed the WebClient issue. So now, a WebClient request created from background thread will receive the response on the same thread. However, if the request is created on the UIthread, the response will come back on the UIthread, this is not recommended. Keeping the UIthread free from heavy processing should be the goal.

How does this impact your application on upgrade from 7.0 to 7.1?

If in 7.0 app, you have an application that created a WebClient request on background thread. Received the response on the UIThread (to update properties on the UI, example add item to your ObservableCollection, bound to ListBox or updated Text of a TextBlock), then on upgrade to 7.1 and running the application as is, will cause

System.UnauthorizedAccessException: Invalid cross-thread access error

You developed your app with an assumption that the response will come back on the UIThread. However, with this change, the response will go back on the background thread causing the cross-thread access error.

Let us look at an example:

Attached is a 7.0 app, where we make a WebClient request on BackgroundWorker thread using Bing Image APIs and get a response back on the UIthread.

private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
       {
           //in a real world scenario this is something where heavy lifting happens on a 

background thread 

 WebClient wc = new WebClient();
           wc.OpenReadCompleted += new OpenReadCompletedEventHandler(wc_OpenReadCompleted);
           UriBuilder fullUri = new UriBuilder("http://api.bing.net/xml.aspx?");
           // Common request fields (required) fullUri.Query = "AppId=XXXXXX" + "&Query=" + _searchterm
           + "&Sources=Image";
           wc.OpenReadAsync(fullUri.Uri);
       }

Then we update the UI after we received the response. Highlighted is the UIthread action.

void wc_OpenReadCompleted(object sender, OpenReadCompletedEventArgs e)
       {
           Stream streamResult = e.Result;
           XElement xmlBingImages = XElement.Load(streamResult);
           string mms = "http://schemas.microsoft.com/LiveSearch/2008/04/XML/multimedia";
           var TEMP = xmlBingImages.DescendantNodes();           
           int totalResults = Convert.ToInt32(xmlBingImages.Descendants("{" + mms + "}Total").First().Value);
           

            
       }

As an exercise, right click on the project from VS2010, upgrade to 7.1

Debug the application. You will see the following exception

And this is how we work around it

Deployment.Current.Dispatcher.BeginInvoke(() =>
            {
                WebClientSampleText.Text = "Total# of Bing image results: " + totalResults.ToString();
            });

Goal of this post is to inform the developers(upgrading from 7.0 to 7.1) about this possible change, they will have to make, if they run into the cross-thread access error.

Thanks

[PS: This was published initially with some glaring grammar mistakes, sorry about that. Was published in a hurry. Got the feedback. It wont be 100% perfect grammatically, but I will try better next time.  Constructive criticism is appreciated.]

WebClient70Sample.zip

We see the following template very often for WP7 apps. 

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

                    <ListBox.ItemTemplate>

                        <DataTemplate>

                            <StackPanel Orientation="Horizontal" Margin="0,0,0,17">

                            <Image Height="100" Width="100" Margin="12,0,9,0" Source="{Binding ImgURL}"/>

                            <StackPanel Width="311">                                   

                                    <TextBlock Text="{Binding LineOne}" TextWrapping="Wrap" Style="{StaticResource PhoneTextExtraLargeStyle}"/>

                                    <TextBlock Text="{Binding LineTwo}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextSubtleStyle}"/>

                                </StackPanel>

                            </StackPanel>

                        </DataTemplate>

                    </ListBox.ItemTemplate>

</ListBox>    

So we decided to move the decoding off to a separate background thread.  The goodness of this change can be seen using the attached sample, LargeListBoxImageDecoding (it’s a huge sample as the images are local in the project).

Here are the pretty diagrams demonstrating the change. 

  This is how it will be for WP7/Mango default:

Here is how it will be with BackgroundCreation

Opt-In property

Moving the image decoding to a background thread resulted in behavioral change for some existing app, so we had to introduce a new property for developers to opt into this goodness for 7.1

http://msdn.microsoft.com/en-us/library/system.windows.media.imaging.bitmapcreateoptions(v=VS.95).aspx

If you see “Do Not use” at the above link, it will be updated soon.

This is a flagwise enum, here is how the combinations should work

The usage of the property for our scenario will be  as highlighted below

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

                    <ListBox.ItemTemplate>

                        <DataTemplate>

                            <StackPanel Orientation="Horizontal" Margin="0,0,0,17">                              

                            <Image Height="100" Width="100" Margin="12,0,9,0" >

                                <Image.Source>

                                    <BitmapImage UriSource="{Binding ImgURL}" CreateOptions="BackgroundCreation"/>  <!-- flip this to none or delay creation to see the impact on the app-->

                                </Image.Source>

                            </Image>

                            <StackPanel Width="311">                                   

                                    <TextBlock Text="{Binding LineOne}" TextWrapping="Wrap" Style="{StaticResource PhoneTextExtraLargeStyle}"/>

                                    <TextBlock Text="{Binding LineTwo}" TextWrapping="Wrap" Margin="12,-6,12,0" Style="{StaticResource PhoneTextSubtleStyle}"/>

                                </StackPanel>

                            </StackPanel>

                        </DataTemplate>

                    </ListBox.ItemTemplate>

                </ListBox>

Impact of BackgroundCreation

Defaults: We recognized offthread-decoding or asynchronous decoding as a good pattern that the developers should follow and wanted to make it a default for the new 7.1 application. Existing 7.0 applications will not be impacted by this change.

So in the mango tools we experimented and kept offthread decoding (BackgroundCreation) as a default. However, we saw several beta developers feel some pain when they upgraded their app from 7.0 to 7.1

Change#1

     BitmapImage b = new BitmapImage();

            b.CreateOptions = BitmapCreateOptions.BackgroundCreation;

            b.SetSource(stream);

            b.PixelHeight, b.PixelWidth

// now do something with b.PixelWidth/PixelHeight, these values are 0 till the decoding is completed. Use mitigation.

Change#2

Mitigations:

For both the cases above, you can resolve by waiting for ImageOpened event, and checking if ImageFailed isn’t fired.

Change#3

This will be a little difficult to imagine. It’s a subtle behavior change that you might notice in your app.

Scenario here is, you update the URL of the image (could be part of listbox item), from URL1 to URL2.

With DelayCreation, since the decoding is happening on the UI thread, the image for URL2 won’t show up till the decoding is completed. As soon as the decoding is completed, URL1 image is replaced by ULR2 image. UI thread is bogged down, so less interactivity.

With BackgroundCreation, however, the decoding will happen on a background thread. Which means the UI thread is free to update the UI; while URL2 image is being decoded in the background, URL1 image is replaced by a momentary “blank” and as soon as the URL2 image is decoded, it appears in place of the blank. Resulting in what might looks like a momentary flicker or change in behavior. Depending on your app, this might be desirable or not.

You will notice this in the sample when you change the URL. Play with the property to see the impact yourself.

As another example, you can experiment with the panorama, create a basic panorama application using the pano template. Add the following code to it  

  <controls:Panorama.Background>

                <ImageBrush>

                    <ImageBrush.ImageSource>

                        <BitmapImage CreateOptions=" BackgroundCreation

" UriSource="PanoramaBackground.jpg"></BitmapImage> <!--or png-->

                    </ImageBrush.ImageSource>

                </ImageBrush>

            </controls:Panorama.Background>

Launch the app on device and see the change

1.  With BackgroundCreation: the app launches and the panorama background animates in, what appears like a flicker. Or a delayed appearance of the background. This is because the image is still being downloaded in the background while everything else has started to appear.
2.  With DelayCreation: the app launches and the panorama background animates in as expected, smoothly without any flicker. This is because, we don’t proceed until the background image decoding is completed.

When do you use BackgroundCreation ?

The question should be other way actually, when to NOT use BackgroundCreation ? If your application is impacted by BackgroundCreation, as described in the previous section, then you shouldn’t use it. Otherwise, in all other scenarios, having BackgoundCreation for images is nothing but goodness for your application’s UIThread.

Use background creation wherever possible as it, in a very subtle way, improves the interactivity of the application.

The goodness of this change is linearly proportional to the size of the images.

[Edit update – 8/1/2011]  - removed the ‘More optimizations’ section as it is no longer relevant for Mango.

 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: 

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.  

Mitigations*

 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">

http://msdn.microsoft.com/en-us/library/system.windows.controls.scrollviewer.manipulationmode(VS.95).aspx

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

            Control,

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

            System

        }

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

        public ManipulationMode ManipulationMode { get; set; }

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.

It's that time of year again - PDC 2010 kicks of tomorrow! Join the Silverlight Performance Team as we take you through the high level analysis of common performance issues that apps commonly run into. I'll be giving a live session titled "Optimizing Performance for Silverlight WP7 Apps" at 3:15pm (PDT)  on day 1 (28 October 2010).

Even if you couldn't make it here to heckle me in person, the rest of the team will be online and answering your questions (or heckling on your behalf) as you watch the live stream via the online player, which you'll be able to find at http://player.microsoftpdc.com 

Make sure to check out the session before mine ("Things I Wish I Knew about Building WP7 Apps" by Jaime Rodriguez) and all of the rest of the Windows Phone 7track. There's other great content at PDC that's worth checking out, but we all know that that's secondary!

See you there!

Here are some tips on how to tweek your list box scroll performance.

Simplify ListBox Item

Listbox's VirtualizingStackPanel (VSP), calculates the height of items currently in the view and buffers the UI containers for a screens worth of items above and below what is currently in the view. This works great if the items are of fixed size. If you change the size of the items, the UI virtualization breaks and you don't get any performance benefits.

• Ensure you have the item data template in a fixed sized container (grid).
• Avoid/remove using complex converters, when the same information can be easily provided by the data object.
• Avoid/remove nested structures, example listbox in a listbox item.
• Strongly recommended to not use user control inside the data template.
• Avoid/remove custom controls from the data template

Load the images in background

If you have refered to the performance document, you will know the importance of keeping the UI thread free for better responsiveness to handle input. This means that if you load the images on the UI thread, an input like flick might be lost. David talks about how to move the image loading to a single background thread in his blog LowProfileImageLoader.

Use Data Virtualization

When using ListBox, UI is virtualized, the data is not -- so although a 1,000 item list only has a fraction of the UI elements created, it needs all 1,000 of the data objects created and loaded, which can be a resource issue (long load times / high memory usage). This is because in desktop Silverlight the ListBox and other controls databind to IEnumerables, where the only option the control has is to enumerate the entire list to find out how large it is. Peter has a solution to this in his post on Data Virtualization.

Do not use ListBox**

If your application demands variable height items, but the number of items is managable enough to keep in memory. You should consider a solution without list box, example: David Anson talks about how to use StackPanel instead of a ListBox in his post on DefferedLoadListBox from Delay in order to get good performance from a scenario that's pretty common for social media applications: a scrolling list of entries with a picture and a brief bit of text. Its easy to try it out for your application.

Do not use Nested ListBox

If you have a need for nested list boxes, you should consider a solution similar to ListBoxGroupie

Other tips/approaches

• HttpWebRequest must be used instead of WebClient. The reason for this is, there is a current platform issue where a request created via WebClient always returns on the UI thread, and again, we know that keeping the UI thread free is important.  Note: this is fixed in Mango, read about it here
• When your list(in pivot/pano) is being populated, if you want to display a progress bar use the high performance progress bar
• Sometimes you bind the list to an observable collection. In that case, Add items to the UI thread in batches every some miliseconds (example add 2 items every 20ms). This keeps the UI thread free for input from the user, avoiding stutters and delays, giving the perception of performance. This is much better than adding all 20 items in one go, drawing 20 items straight on the UI thread will keep it busy and wont take in the input from user, example the flick gesture for scroll. BingImageSearch is an example of one such application.
• Peter has a good design example, where he stops loading the items if the list is scrolling. He elaborates about it in his blog on LazyListBox

Finally, we are incorporating all the feedback into the platform and your comments/feedback/questions are appreciated.

Thanks

Silverlight Windows Phone 7 Perfomance Team