Dynamic -Resolution Switching

Dynamic -Resolution SwitchingScreenPlay provides support for externally connected displays, -such as TV-out. Previous versions of Symbian and the non-ScreenPlay variant -consider the size of all displays to be fixed, assuming them to be built into -the phone. However, for High-Definition Multimedia Interface (HDMI) and composite -video connectors, there is a range of resolutions that can change dynamically. -ScreenPlay provides an optional feature that supports switching between resolutions -at runtime. -

Variant: ScreenPlay.

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.

-Graphics -Concepts - - + + + + + +Dynamic +Resolution SwitchingScreenPlay provides support for externally connected displays, +such as TV-out. Previous versions of Symbian and the non-ScreenPlay variant +consider the size of all displays to be fixed, assuming them to be built into +the phone. However, for High-Definition Multimedia Interface (HDMI) and composite +video connectors, there is a range of resolutions that can change dynamically. +ScreenPlay provides an optional feature that supports switching between resolutions +at runtime. +

Variant: ScreenPlay.

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.

+Graphics +Concepts + +

\ No newline at end of file