IMG notes for Silverlight and Windows Phone 7

During WP7 program development, a large number of images are used on the UI. You may think that using image is a simple task. You don't need to use a blog article to describe it: Just set the source attribute of a URI to the image? However, there are other things to consider. There are a lot of small details here, if you know it, it will be helpful to your program, especially when you want to develop software with better experience and less memory usage (mobile development is very important ). These tips apply not only to WP7 Mobile Phone development, but also to Silverlight desktop programs. However, in mobile phone development, it is very important to grasp the skills that can turn a good program into an excellent program performance detail. To point this out, we provide an example to implement these small details.

JPG vs PNG

If you want to make a choice between jpg and PNG, use JPG for all your opaque images. In Windows Phone 7, JPG decoders are much faster than PNG decoders. Of course, if your image needs to be transparent, PNG is your only choice.

Resource vs content

In Visual Studio, set "build type" to "resource" or "content", and the image will be compiled into a part of the window phone xap file. Since they are all packaged into xap, you may not see the difference between them at first. They seem to be all the way. But when you open the external shell of xap(renamed as A. ZIP file and decompress it): You can see all the "content" files, but cannot find the "resource" files. Why? Because the "resource" type file is embedded in the program set (that is, the DLL file ). So why are we so concerned about where the "resource" file is embedded. This is because the larger the DLL package of your program, the slower your program starts. On the other hand, compared with loading images from a disk, the image loading with embedded DLL is faster.

Summary: setting it to "content" will make the program start faster, and setting it to "resource" will make the program respond faster.

It is also worth mentioning that they have different URI formats. You can refer to the following example:

Content: <Image Source = "/imagesascontent/smiley1.png"/>

Resource: <Image Source = ".. \ imagesasresource \ smiley3.png"/>

Async vs. Sync loading of images

If you have developed the imaging API, you will find bitmapimage class. bitmapimage will do a lot of work behind the scenes when creating an image. It can load content in two modes:

 
Bitmapimage. urisource = urisource; // loads the image via Uri, asynchronously
Bitmapimage. setsource (Stream); // loads the image from stream, synchronously

Note that loading images asynchronously does not mean completely off-thread. This is because the decoding of images occurs on the UI thread. For more information about asynchronously loading images while maintaining the UI thread response, see David Anson's blog.

The following are some knowledge about Synchronous vs asynchronous loading:

1. If an incorrect image file is synchronously loaded, an exception occurs.

2. If an incorrect image file is asynchronously loaded, the imagefailed event is triggered.

3. If a correct image file is asynchronously loaded, the imageopened event will be triggered.

4. If a correct image file is synchronously loaded, the imageopened event will not be triggered.

Their differences can be demonstrated through the sample code provided by me (on the loading page)

Image caching

This is an important aspect of the image, and msdn has very few records on it. Even if the source attribute is cleared in WP7 platform and the image is removed from the visual tree, the image memory will not be released. In fact, what you see is the image cache. This is a reserved performance optimization to avoid loading and decoding identical images over and over again. In WP7, a buffer is opened in the memory. We can use it to conveniently and quickly reuse image resources. This is similar to the browser cache.

Although image caching is helpful for improving performance, it sometimes increases unnecessary memory consumption. In particular, images that are not displayed will be recycled. During the running process of the program, the image cache will always occupy the memory space. However, you can also use the following code to delete Cache Information:

Bitmapimage = image. source as bitmapimage;

Bitmapimage. urisource = NULL;

Image. Source = NULL;

Reasonable Use of the above Code can reduce memory usage. Reducing memory usage is of great help in mobile phone development. In the example program, the "Caching" Page monitors the display and clearing of cache memory usage. In the example, we can see that there is a 3 MB memory difference.

Bitmapcreateoptions

This is a fast and interesting part. When creating a bitmapimage, you may have the following question: Why do you think the image size is still not returned when you have created the image? This is because the createoptions attribute is set to "delaycreation" by default, that is, when bitmapimage is set to the source attribute of an image or the imagebrush of the visualization tree, this object is created only when it is actually needed. This allows creating many bitmapimages when the program starts to run, but does not consume any resources (CPU or memory) until the program needs specific images to actually create them. If you want to force the creation operation immediately, set createoptions to "NONE. Another value of createoptions is "ignoreimagecache", which is not very useful in many scenarios and must be combined with design tools (such as blend ).

In the example program, on the "createoptions" Page, use create/show/clear to control the value of createoptions as delaycreation, none, and monitor the image size changes.

Custom Decoding

All APIs related to images are decoded Based on the image resolution (except downsampling for downsampling to reduce pixel sampling, which will be introduced later ). In any case, this can be used to display images on mobile phones. If you download a batch of 320x320 images, but only display them as small as 32x32, decoding with the original resolution will waste the right memory resources.

On the Windows Phone platform, we provide picturedecoder application interfaces for programmers to decode images at custom resolutions:

Image. Source = picturedecoder. decodejpeg (jpgstream, 192,256 );

Note: There is a bug in the currently released API. The image height and width attribute values are exchanged. Therefore, you must set the width to the height. This problem will be fixed by ms in the future. I also accidentally discovered this problem.

To view memory growth, go to the "m decoding" page of the sample program. Monitor memory usage in two resolutions.

Auto downsampling

This is the last thing we need to know when processing WP7 platform images. Background is a special element and is limited to 2048x2048. If the image size exceeds this limit, it is cropped. This means that an image with a length greater than 2048 pixels is used and the image is not displayed completely. To avoid this situation, the WP7 platform will automatically reduce the pixel size by 2048x2048. This is different from the desktop Silverlight application. Therefore, Silverlight does not have the preceding restrictions.

In the example program, I used an image with a resolution of 1500x1051, and the final image was reduced to X pixels.

As a matter of fact, there are still a lot of things worth studying in detail. Here is just a reference, and I hope to discuss this with you. Thank you for reading this article. I hope it will help you.

Limited capabilities. If any error occurs, please correct it.