Phạm Tiên Sinh

When talking about performance issue, a couple of concepts about threads need to be investigated.

There are three kinds of threads in WP7:

The UI thread is the most important thread, it is responsible for reading uers’ inputs, drawing UI Elements and calling event handlers. Because of its high importance, it is necessary to keep UI thread free from heavy processing. If the UI thread is blocked due to some heavy tasks, our UI is also blocked and not responsive to users’ interaction.

“WP7 devices have a separate GPU which is optimized for handling graphics operations such as displaying, scaling, rotating, and 3D. Silverlight on WP7 has the ability to use that GPU, which can greatly increase graphics performance. It does this by allowing a “snapshot” of a visual, called a Bitmap Cache, to be handed over to the GPU for manipulation.”

Since then, to control and manage the GPU, there is a thread called render thread (sometimes it is also called compositor thread). It makes of the GPU to manipulate animations, including opacity, transform and projection animations. All action performed by this thread is GPU accelerated. It is recommended to leverage render thread to alleviate UI thread. However, our animations are not always processed by the render thread. If OpacityMask or non-rectangular Clip is applided or texture size is greater than 2000x2000 pixels, animations will be processed by UI thread instead.

Rendered thread only work with elements that are bitmap cached. Attach the following code in the constructor of the start page to be able to see what UI Elements are cached:

Application.Current.Host.Settings.EnableCacheVisualization = true;

With cache visualization enabled, elements that are cached will be colored in blue and have some transparency. The more elements are cached, the more fill rate (fill rate is the number of screens per second, 1 screen is 480x800 pixels) our GPU has to process. There will be a visible degradation if the number of screen per second exceed 2. Therefore leveraging GPU does not mean bitmap caching every element on the screen. When our application starts suffering from low fps, it is necessary to choose what elements to cache. Elements that changes visually too often may invalidate the cache that is processing by GPU, therefore they do not require CPU acceleration, and thus we do not need to cache those.

The last thread to be mentioned is worker thread. I will not talk about the media decoding thread as it is pretty straight forward as its name is. I want explain more about the BackgroundWorker thread which is much more important in optimizing performance. So what is a background worker thread? “The BackgroundWorker class allows you to run an operation on a separate, dedicated thread. Time-consuming operations like downloads and database transactions can cause your user interface (UI) to seem as though it has stopped responding while they are running. When you want a responsive UI and you are faced with long delays associated with such operations, the BackgroundWorker class provides a convenient solution.”

The following example illustrates how to use background worker:

            ProgressBar progressBar1 = new ProgressBar();
            LayoutRoot.Children.Add(progressBar1);

            BackgroundWorker bw = new BackgroundWorker();
            bw.WorkerReportsProgress = true;

            // DoWorkEventHandler is executed on a seperate thread
            DoWorkEventHandler dwEH = null;
            dwEH = (o, e) => {
                int input = (int) e.Argument;
                //a long running operation
                for (int i = 1; i < 11; i++) {
                    Thread.Sleep(input);
                    bw.ReportProgress(i * 10);
                }
                e.Result = "Background Worker completed successfully";
            };
            bw.DoWork += dwEH;

            // reported progress value is passed to here
            ProgressChangedEventHandler pcEH = null;
            pcEH = (o, e) => {
                progressBar1.Value = e.ProgressPercentage;
            };
            bw.ProgressChanged += pcEH;

            // Things to do after DoWork finish
            RunWorkerCompletedEventHandler rwcEH = null;
            rwcEH = (o, e) => {
                MessageBox.Show((string) e.Result);
                // unregister event handlers to make sure memory
                // allocated can be released properly
                bw.DoWork -= dwEH;
                bw.ProgressChanged -= pcEH;
                bw.RunWorkerCompleted -= rwcEH;
            };
            bw.RunWorkerCompleted += rwcEH;

            bw.RunWorkerAsync(1000);

I didn’t often need this functionality however in the situation when it came in necessary to have an object to deep copied, I found that it is better and more convenient to have an object-deep-copier rather than to copy each attribute invidually. After a bit googling, I tried to subclass the ICloneable interface, but unfortunately it was obsoleted in the Silverlight 4 APIs. I was a little bit frustrated about this, but later thanks to this post http://blog.vascooliveira.com/how-to-duplicate-entity-framework-objects/ I came up with another solution.

The answer is underlying in using Data Contract Serializer. Basically what to do is using WriteObject() function of Data Contract Serializer to serialize an instance of a type into an XML stream, then we use ReadObject() to load it from the XML stream.

/// <summary>
/// Provides a method for performing a deep copy of an object.
/// Binary Serialization is used to perform the copy.
/// </summary>
public static class ObjectCopier {
    /// <summary>
    /// Perform a deep Copy of the object.
    /// </summary>
    /// <typeparam name="T">The type of object being copied.</typeparam>
    /// <param name="source">The object instance to copy.</param>
    /// <returns>The copied object.</returns>
    public static T Clone<T>(this T source) {
        DataContractSerializer dcSer = new DataContractSerializer(source.GetType());
        MemoryStream memoryStream = new MemoryStream();
        dcSer.WriteObject(memoryStream, source);
        memoryStream.Position = 0;
        T newObject = (T)dcSer.ReadObject(memoryStream);
        return newObject;
    }
}

A small note to be noticed, in order to mark an object type as Data Contract, we use the keyword [DataContract] before declaring it, and to mark an attribute as Data Member to instruct what attributes to be serialized, we apply [DataMember] keyword to those attributes.

namespace TestApplication {
    public partial class MainPage : PhoneApplicationPage{
        public MainPage() {
            InitializeComponent();
            Place a = new Place() { x = 1, y = 2};
            Place b = a.Clone();
            Debug.WriteLine("a.x = " + a.x + " ------- a.y = " + a.y + " ");
            Debug.WriteLine("b.x = " + b.x + " ------- b.y = " + b.y + " ");
        }
    }

    [DataContract]
    public class Place {
        [DataMember]
        public int x = 0;

        public int y = 0;
    }
}

As x is not marked as Data Member, it is not included to the XML stream when the object a is serialized and, as a result, when object b is cloned from object a, attribute x is not copied.

And thus the debug output is:

a.x = 1 ------- a.y = 2
b.x = 1 ------- b.y = 0