|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-0EBE5733-A267-5F4A-85AD-87C3ECF80731" xml:lang="en"><title>Dynamic |
|
13 Resolution Switching</title><shortdesc>ScreenPlay provides support for externally connected displays, |
|
14 such as TV-out. Previous versions of Symbian and the non-ScreenPlay variant |
|
15 consider the size of all displays to be fixed, assuming them to be built into |
|
16 the phone. However, for High-Definition Multimedia Interface (HDMI) and composite |
|
17 video connectors, there is a range of resolutions that can change dynamically. |
|
18 ScreenPlay provides an optional feature that supports switching between resolutions |
|
19 at runtime. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
20 <p> <b>Variant</b>: <xref href="GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C.dita">ScreenPlay</xref>. </p> |
|
21 <section id="GUID-374864AA-3757-4BD9-A5EB-4AC0E6DDD198"><title>The pre-ScreenPlay background</title> <p>Early devices typically |
|
22 had a screen size of 220 x 176 pixels. Over time, these were followed by higher |
|
23 resolution screens, such as 440 x 252 pixels. Applications that were designed |
|
24 for 220 x 176 pixel screens could run on 440 x 252 pixel screens because the |
|
25 Window Server simply scaled the pixels by a factor of two. </p> <p>However, |
|
26 this approach did not work when phones with 320 x 240 pixel screens were introduced, |
|
27 because each axis required a different scaling factor. Symbian introduced |
|
28 the <b>screen mode</b> feature to handle this and similar use cases. Device |
|
29 creators define in the <xref href="GUID-1D529BDC-6665-58E2-AB3F-7023D8A84F69.dita">wsini.ini |
|
30 file</xref> a number of screen modes for each physical screen on the device. |
|
31 For each screen mode the device creator defines parameters to control the |
|
32 offset from the top left corner of the screen, the height and width in both |
|
33 pixels and twips, <i>X</i> and <i>Y</i> axis scaling factors and so on. The |
|
34 Window Server uses these to position and scale old applications so that they |
|
35 can run on new phones with higher resolutions, as shown in the following diagram |
|
36 (which is not drawn to scale). The screen mode is still used in the same way |
|
37 in the <xref href="GUID-F64E6551-670E-5E12-8103-DE504D3EC94F.dita">non-ScreenPlay |
|
38 variant</xref>. </p> <fig id="GUID-FF86B974-1B1E-5EE1-A88A-9CD11B213A9B"> |
|
39 <title>The screen mode enables old applications to run on new |
|
40 phones with higher resolutions </title> |
|
41 <image href="GUID-AFC49653-78E6-5639-911C-E02AEB08AFFC_d0e191929_href.png" placement="inline"/> |
|
42 </fig> <p>There are several similar use cases, such as swapping between portrait |
|
43 and landscape orientations and flip phones that have a flap that, when closed, |
|
44 partially obscures the main screen. The Window Server uses the screen mode |
|
45 parameters to display applications differently depending on whether the phone |
|
46 is in portrait or landscape orientation and whether the flap is open or closed. |
|
47 The screen mode represents the area that is presented to the application and |
|
48 is available to application developers through <xref href="GUID-30479BE3-296E-3B4D-914D-B080ABD733E4.dita#GUID-30479BE3-296E-3B4D-914D-B080ABD733E4/GUID-8E1B5729-FD1C-3D4A-AC73-C6364E7D5BBF"><apiname>CWsScreenDevice::SizeInPixels()</apiname></xref>. </p> <p>Defining |
|
49 the screen modes in the <xref href="GUID-1D529BDC-6665-58E2-AB3F-7023D8A84F69.dita">wsini.ini |
|
50 file</xref> in this way means that all possible screen sizes and resolutions |
|
51 must be fixed and known at ROM building time. This approach has limitations |
|
52 when working with technologies such as HDMI and composite video connectors, |
|
53 where there is a very wide range of possible resolutions that may not be known |
|
54 until runtime. </p> </section> |
|
55 <section id="GUID-139F6C69-85CD-4796-AE8D-A48EEAEB5294"><title>The ScreenPlay approach</title> <p>In ScreenPlay the actual |
|
56 resolution of the full composition/display area can be determined at runtime. |
|
57 The full UI area is mapped to fill this display area but may be a lower virtual |
|
58 resolution, which is scaled. The render stage chain handles the |
|
59 scaling and positioning of applications and any external surfaces within the |
|
60 UI, and the composition engine performs the scaling of the pixel data to the |
|
61 actual display area at physical resolution. This has the advantage that the |
|
62 scaling can be handled by the graphics acceleration hardware, if it is available. </p> <p>Another |
|
63 advantage of this approach is that it enables dynamic scaling of the pixels. |
|
64 Usually pixels are square on a mobile phone display, but not square on many |
|
65 external displays. When the square pixels from the device are displayed on |
|
66 such a display, they may need to be scaled by different arbitrary factors |
|
67 on each axis. This is called <b>anisotropic scaling</b>. In contrast, <b>isotropic |
|
68 scaling</b> means that both pixel axes are scaled by the same arbitrary factor. </p> <p>The |
|
69 following diagram illustrates how the full UI area is mapped to fill the display/composition |
|
70 area. The application's area (which corresponds to the screen mode) is referred |
|
71 to as the <b>application extent</b> in ScreenPlay. </p> <fig id="GUID-724DB4EE-1F45-58D9-889C-B42ECEE7208D"> |
|
72 <title>Coordinate spaces in ScreenPlay </title> |
|
73 <image href="GUID-A719FDFA-903B-5340-AA47-9E5B22DBB253_d0e191975_href.png" placement="inline"/> |
|
74 </fig> <p>ScreenPlay handles application sizing and positioning in a fundamentally |
|
75 different way from the non-ScreenPlay variant. Using a fixed offset to position |
|
76 the application within the screen is inadequate when connecting to an external |
|
77 HDMI display, for example, when the resolution may not be known until runtime. |
|
78 For example, the offset designed for a QVGA display does not position the |
|
79 application correctly in a higher resolution display, as shown in the following |
|
80 diagram, where the red cross indicates the offset for a QVGA display. </p> <fig id="GUID-A2816D08-B61F-5605-B6AF-A9D186F6BED5"> |
|
81 <title>A fixed offset and several display resolutions (not drawn |
|
82 to scale) </title> |
|
83 <image href="GUID-B2E63B13-7B72-5CBF-ACD0-1F2D2E1EEF19_d0e191986_href.png" placement="inline"/> |
|
84 </fig> <p>In ScreenPlay there is no scaling of the application extent relative |
|
85 to the full UI area—there is always a 1:1 pixel correspondence between them. |
|
86 In addition, although supported, the screen mode offset is not necessarily |
|
87 used. Instead, the render stage chain selects an appropriate virtual resolution |
|
88 and handles the positioning—for example, centering it and using a best fit |
|
89 algorithm so that it takes up as much of the screen as possible or using the |
|
90 offset as a minimum margin size. The device creator can choose how to implement |
|
91 this in the render stages. In order to position the application correctly |
|
92 within the UI area, the Window Server gets the positioning information from |
|
93 the first render stage in the chain when the configuration or screen mode |
|
94 changes. </p> <p>ScreenPlay supports fixed screen modes in the <xref href="GUID-1D529BDC-6665-58E2-AB3F-7023D8A84F69.dita">wsini.ini |
|
95 file</xref>, although the scaling parameters are not used. However, the screen |
|
96 mode width and height in pixels and twips when specified and used together, |
|
97 provide the pixel aspect ratio. In order to maintain backwards compatibility, |
|
98 render stages should respect this aspect ratio whenever possible. </p> <p>It |
|
99 is possible for applications to determine and draw to the UI area outside |
|
100 the application extent using the APIs described below. However, <b>dynamic |
|
101 screen modes</b> provide an alternative mechanism for existing applications |
|
102 to access the full UI area. This is particularly suitable for HDMI and similar |
|
103 technologies where the resolution may not be known until runtime. To use this |
|
104 approach, the device creator must define one or two screen modes in the <xref href="GUID-1D529BDC-6665-58E2-AB3F-7023D8A84F69.dita">wsini.ini file</xref> and |
|
105 set their height and width in pixels to -1. One dynamic screen mode then represents |
|
106 the current display configuration and the other one, if present, represents |
|
107 the configuration when the screen is rotated by 90º or 270º. Using dynamic |
|
108 screen modes means that the display configuration can be changed at runtime |
|
109 according to the hardware that is available and detected by the composition |
|
110 engine. </p> <p>When a dynamic screen mode is used, the application extent |
|
111 always fills the full UI space and the area returned by <xref href="GUID-30479BE3-296E-3B4D-914D-B080ABD733E4.dita#GUID-30479BE3-296E-3B4D-914D-B080ABD733E4/GUID-8E1B5729-FD1C-3D4A-AC73-C6364E7D5BBF"><apiname>CWsScreenDevice::SizeInPixels()</apiname></xref> always |
|
112 matches the actual resolution that is in use. </p> </section> |
|
113 </conbody><related-links> |
|
114 <link href="GUID-99BC101A-9466-59EE-B5C9-7622BAF6E6FF.dita"><linktext>Graphics |
|
115 Concepts</linktext></link> |
|
116 |
|
117 |
|
118 </related-links></concept> |