×

Resolution specific considerations

Multi-resolution apps for Windows Phone 8 (MSDN) covers the topic of determining the resolution at runtime and ensuring that application's UI scales correctly on all Windows Phone 8 devices. This page provides more details related to optimising applications for 1080p in particular, such as, how to detect whether your app is running in a 1080p device, how to utilize higher resolution assets for 1080p screens, and possible memory consequences when dealing with more content and in higher resolution.

Resolution detection code update

The following code block provides an updated version of ResolutionHelper.cs presented in ​Multi-resolution apps for Windows Phone 8 with 1080p support.

public enum Resolutions { WVGA, WXGA, HD720p, HD1080p };

public static class ResolutionHelper
{
    static private Size _size; 

    private static bool IsWvga
    {
        get
        {
            return App.Current.Host.Content.ScaleFactor == 100;
        }
    }

    private static bool IsWxga
    {
        get
        {
            return App.Current.Host.Content.ScaleFactor == 160;
        }
    }

    private static bool Is720p
    {
        get
        {
            return (App.Current.Host.Content.ScaleFactor == 150 && !Is1080p);
        }
    }

    private static bool Is1080p
    {
        get
        {
            if(_size.Width == 0)
            {
                try
                {
                    _size = (Size)DeviceExtendedProperties.GetValue("PhysicalScreenResolution");
                }
                catch (Exception)
                {
                    _size.Width = 0;
                }
            }
            return _size.Width == 1080;
        }
    }

    public static Resolutions CurrentResolution
    {
        get
        {
            if (IsWvga) return Resolutions.WVGA;
            else if (IsWxga) return Resolutions.WXGA;
            else if (Is720p) return Resolutions.HD720p;
            else if (Is1080p) return Resolutions.HD1080p;
            else throw new InvalidOperationException("Unknown resolution");
        }
    }
}

Note that 720p and 1080p cannot be differentiated using App.Current.Host.Content.ScaleFactor or Application.Current.Host.Content.ActualHeight as they both share the same values, 150 and 853 respectively.

High resolution graphics

To make an application look as good as possible across the range of devices with several different resolutions, it is suggested to simply use assets designed for 1080p resolution and let the Windows Phone OS properly downscale them as needed. Such assets include application graphics, splash screen, lockscreen, and live tiles.

The operating system automatically downscales the app’s 1080p assets when running the app on a 720p device, and retains the high DPI when running the app on a 1080p device. It is highly encouraged to keep your application as a single XAP file that supports all screen sizes and resolutions. That XAP file only needs to provide the high resolution assets; they will be scaled down by the OS as needed.

However, if the package is designed to support both 16:9 and 15:9 aspect ratio devices, to handle aspect ratio considerations you may have to provide two variants of the high resolution graphics and decide at run time which one to use:

public class MultiResImageChooserUri
{
    public Uri BestResolutionImage
    {
        get
        {
            switch (ResolutionHelper.CurrentResolution)
            {
                case Resolutions.HD1080p:
                case Resolutions.HD720p:
                    //return 16:9 aspect ratio asset, high res
                    return new Uri("Assets/MyImage.screen-1080p.jpg", UriKind.Relative);
                case Resolutions.WXGA:
                case Resolutions.WVGA:
                    // return 15:9 aspect ratio asset, high res
                    return new Uri("Assets/MyImage.screen-wxga.jpg", UriKind.Relative);
                default:
                    throw new InvalidOperationException("Unknown resolution type");
            }
        }
    }
}

Some thought should be given to loading assets from the remote servers, and aim at providing the best practical resolution while keeping the data transfer costs and and loading time as low as possible. In Music Explorer example application this is achieved by loading the image best suited for device's resolution, determined by the ResolutionHelper (shown in the section Resolution detection code update above). The 320x320 images are used only in 1080p devices, while the 200x200 images were seen to be sharp and crisp enough for devices with smaller resolution.

...

public class ArtistModel : INotifyPropertyChanged
{
    ...

    /// <summary>
    /// Artist's ThumbUri property.
    /// This property is used in the UI to display the image in Uri using a Binding.
    /// </summary>
    public Uri ThumbUri
    {
        get
        {
            if (_thumb320Uri != null && ResolutionHelper.CurrentResolution == Resolutions.HD1080p)
            {
                return _thumb320Uri;
            }
            else if (_thumb200Uri != null)
            {
                return _thumb200Uri;
            }
            else if (_thumb100Uri != null)
            {
                return _thumb100Uri;
        }
            else
            {
                return new Uri("/Assets/thumb_100_placeholder.png",
                               UriKind.Relative);
            }
        }
    }
    ...
}

Figure 1. Smaller display with 200x200 px images

Figure 2. Large display with 320x320 px images

Application's memory consumption can be optimised when loading large images:

...
var bmp = new BitmapImage();
 
// no matter the actual size, this bitmap is decoded to 480 pixels width
// (aspect ratio preserved) and only takes up the memory needed for this size
bmp.DecodePixelWidth = 480; 

bmp.UriSource = new Uri(@"Assets\Demo.png", UriKind.Relative);
ImageControl.Source = bmp;
...

For more information on multi-resolution support, see ​​Windows Phone 8: XAML Application Development (video, from 08:20 onwards).

Note that for XNA and DirectX apps, bitmaps are scaled by the hardware; developers cannot provide higher-resolution assets for 1080p devices in Windows Phone 8.

Splash screen guidance

To have a full screen splash screen displayed on 720p/1080p device, a 720x1280 pixel splash screen image SplashScreenImage.Screen-720p.jpg should be provided by the solution. The image will go full screen also in 1080p devices due to up-scaling. In order to have a pixel perfect splash screen for 1080p devices and avoid up-scaling, a full 1080x1920 pixel splash screen image can be provided in the 720p splash screen file. It will automatically be scaled down on 720p devices, while being displayed in native resolution on 1080p devices.

Note that although the ​current guidance from Microsoft regarding splash screens may encourage the use of a single splash screen file named SplashScreenImage.jpg containing a 768×1280 pixel image, an image of that size does not scale correctly on 1080p devices, it leaves an empty area at the top of the screen.

Lense tile

1080p devices use HD720p lense tile variant, see ​Lens design guidelines for Windows Phone. but a higher resolution image (i.e., 1.5x the recommended size for 720p) can be provided in the Lens.Screen-720p.png file for a more crisp look on 1080p devices.

Tiles

Tiles in 1080p are smaller in size due to the adoption of 3 column layout. Tiles are scaled down automatically by the platform, so there is no need for a developer to provide additional 1080p tiles. For more detailed information, please see section Live tiles in chapter Design considerations.

Scaling factor considerations

Controls

On a 768p (WXGA) device, a control with the logical size of 100px is scaled up by a factor of 1.6, resulting in a control with 160px physical size once rendered on the screen.

On a 1080p device the reported scale factor is 1.5, but the real scaling is done with a factor of 2.25 (1.5 x 1.5), so a 100px control will end up having a physical size of 225px.

This means that in order to have a control of the same physical size on both 768p and 1080p devices, its logical size will have to be scaled down with a factor of 1.6/2.25 = 0.7111 on 1080p devices. This is visualised using Music Explorer as an example. The tile controls share the same physical value between the devices with different resolutions, the margins of the control explaining the small difference in size of the actual photo of the artist.

public class MainViewModel : INotifyPropertyChanged
{
    ...

    public void LoadData()
    {
        ...

        foreach (ArtistModel m in App.ViewModel.LocalAudio)
        {
            if (m.Name.Contains("TitlePlaceholder")) continue;
            m.ItemHeight = "205";
            m.ItemWidth = "205";

            if (IsBigScreen)
            {
                m.ItemHeight = "146"; // ~= 205*0.7111
                m.ItemWidth = "146"; // ~= 205*0.7111 
            }
        }
        ...
    }
    ...
}

Figure 3. Images on smaller screen have logical size of 205

Figure 4. Same physical size on large display requires scaling by 0.7111

Fonts

For detailed information on font scaling, see section Font sizes in chapter Design considerations.

High-definition video delivery to 1080p devices

Windows Phone will continue to display a video stream at the highest resolution allowed by the display, the same as it does today. To help developers decide on the best stream to render, they should use the PhysicalScreenResolution property. If the developer wishes to use the physical dimensions of the screen to select a stream, the screen size calculations shown in What is a big screen? section can be used to make that determination.

Microsoft's Smooth Streaming technology – which allows for video streaming at a variable bitrate, balancing device's capabilities (device resolution, hardware codecs) with network conditions and power usage – is highly recommended. At the time of writing, the PlayerFramework component does not support 1080p devices, but its implementation can be easily updated by adding 1080p resolution detection in Phone.SL.Adaptive/ResolutionHelper.cs which then enables setting the correct MaxPixels value in Phone.SL.Adaptive/AdaptiveStreamingManager.cs. Progressive download is also supported with up to 1080p resolution at 30fps (max).

For details about hardware supported video and audio codecs, see ​​Supported media codecs for Windows Phone.

Memory considerations

With larger screen and better resolutions, the graphics of the application are likely to use more memory than in devices of lesser resolution and display size. Applications can request more memory with ID_FUNCCAP_EXTEND_MEM entry in the app manifest file, as instructed in ​App memory limits for Windows Phone 8.

Using ID_FUNCCAP_EXTEND_MEM flag grants a higher memory allocation instead of the default lower level. It enforces the maximum memory limit by phone type: 180 MB on lower-memory phones; 380 MB on phones with over 1 GB memory; and 570 MB on devices with 2 GB memory.

This should be noted especially when writing applications using ​Panorama control with its long horizontal canvas and up to five ​PanoramaItems, which can get graphically very complex. The navigation transitions of the Windows Phone Toolkit are known to be particularly memory hungry : a memory consumption peak is often reached when navigating from/to the page containing the panorama.


Last updated 3 February 2014

Back to top

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×