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.

+The screen mode enables old applications to run on new + phones with higher resolutions + +

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.

+Coordinate spaces 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.

+A fixed offset and several display resolutions (not drawn + to scale) + +

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.