Dynamic Resolution Switching

The pre-ScreenPlay background

Early devices typically had a screen size of 220 x 176 pixels. Over time, these were followed by higher resolution screens, such as 440 x 252 pixels. Applications that were designed for 220 x 176 pixel screens could run on 440 x 252 pixel screens because the Window Server simply scaled the pixels by a factor of two.

However, this approach did not work when phones with 320 x 240 pixel screens were introduced, because each axis required a different scaling factor. Symbian introduced the screen mode feature to handle this and similar use cases. Device creators define in the wsini.ini file a number of screen modes for each physical screen on the device. For each screen mode the device creator defines parameters to control the offset from the top left corner of the screen, the height and width in both pixels and twips, X and Y axis scaling factors and so on. The Window Server uses these to position and scale old applications so that they can run on new phones with higher resolutions, as shown in the following diagram (which is not drawn to scale). The screen mode is still used in the same way in the non-ScreenPlay variant.

There are several similar use cases, such as swapping between portrait and landscape orientations and flip phones that have a flap that, when closed, partially obscures the main screen. The Window Server uses the screen mode parameters to display applications differently depending on whether the phone is in portrait or landscape orientation and whether the flap is open or closed. The screen mode represents the area that is presented to the application and is available to application developers through CWsScreenDevice::SizeInPixels().

Defining the screen modes in the wsini.ini file in this way means that all possible screen sizes and resolutions must be fixed and known at ROM building time. This approach has limitations when working with technologies such as HDMI and composite video connectors, where there is a very wide range of possible resolutions that may not be known until runtime.

The ScreenPlay approach

In ScreenPlay the actual resolution of the full composition/display area can be determined at runtime. The full UI area is mapped to fill this display area but may be a lower virtual resolution, which is scaled. The render stage chain handles the scaling and positioning of applications and any external surfaces within the UI, and the composition engine performs the scaling of the pixel data to the actual display area at physical resolution. This has the advantage that the scaling can be handled by the graphics acceleration hardware, if it is available.

Another advantage of this approach is that it enables dynamic scaling of the pixels. Usually pixels are square on a mobile phone display, but not square on many external displays. When the square pixels from the device are displayed on such a display, they may need to be scaled by different arbitrary factors on each axis. This is called anisotropic scaling. In contrast, isotropic scaling means that both pixel axes are scaled by the same arbitrary factor.

The following diagram illustrates how the full UI area is mapped to fill the display/composition area. The application's area (which corresponds to the screen mode) is referred to as the application extent in ScreenPlay.

ScreenPlay handles application sizing and positioning in a fundamentally different way from the non-ScreenPlay variant. Using a fixed offset to position the application within the screen is inadequate when connecting to an external HDMI display, for example, when the resolution may not be known until runtime. For example, the offset designed for a QVGA display does not position the application correctly in a higher resolution display, as shown in the following diagram, where the red cross indicates the offset for a QVGA display.

In ScreenPlay there is no scaling of the application extent relative to the full UI area—there is always a 1:1 pixel correspondence between them. In addition, although supported, the screen mode offset is not necessarily used. Instead, the render stage chain selects an appropriate virtual resolution and handles the positioning—for example, centering it and using a best fit algorithm so that it takes up as much of the screen as possible or using the offset as a minimum margin size. The device creator can choose how to implement this in the render stages. In order to position the application correctly within the UI area, the Window Server gets the positioning information from the first render stage in the chain when the configuration or screen mode changes.

ScreenPlay supports fixed screen modes in the wsini.ini file, although the scaling parameters are not used. However, the screen mode width and height in pixels and twips when specified and used together, provide the pixel aspect ratio. In order to maintain backwards compatibility, render stages should respect this aspect ratio whenever possible.

It is possible for applications to determine and draw to the UI area outside the application extent using the APIs described below. However, dynamic screen modes provide an alternative mechanism for existing applications to access the full UI area. This is particularly suitable for HDMI and similar technologies where the resolution may not be known until runtime. To use this approach, the device creator must define one or two screen modes in the wsini.ini file and set their height and width in pixels to -1. One dynamic screen mode then represents the current display configuration and the other one, if present, represents the configuration when the screen is rotated by 90º or 270º. Using dynamic screen modes means that the display configuration can be changed at runtime according to the hardware that is available and detected by the composition engine.

When a dynamic screen mode is used, the application extent always fills the full UI space and the area returned by CWsScreenDevice::SizeInPixels() always matches the actual resolution that is in use.