|
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-D93978BE-11A3-5CE3-B110-1DEAA5AD566C" xml:lang="en"><title>The |
|
13 ScreenPlay Graphics Architecture</title><shortdesc>This topic provides an introduction to ScreenPlay and its architecture. |
|
14 ScreenPlay is a new graphics architecture, introduced in Symbian^3 (S^3). |
|
15 ScreenPlay enables device creators to take advantage of improved software |
|
16 performance, hardware acceleration and third party graphics engines. ScreenPlay |
|
17 is sometimes known as the <b>New Graphics Architecture (NGA)</b>. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
18 <p>ScreenPlay is a response to new requirements and developments in device |
|
19 hardware models. For example, ScreenPlay can support graphics accelerators |
|
20 and graphics processing units (GPUs) and non-uniform memory models as well |
|
21 as uniform memory models. A non-uniform memory model is an architecture in |
|
22 which a GPU has a completely different processing area from the CPU such that |
|
23 the GPU memory is not available to the CPU and vice versa. ScreenPlay can |
|
24 handle non-uniform memory models without the need to copy buffers between |
|
25 the different processing areas. </p> |
|
26 <section id="GUID-D4071308-2FA1-4B04-9AC2-926E1D619D08"><title>Key features</title><ul> |
|
27 <li id="GUID-0325A4C9-BAA3-5FA3-8389-BB406C020F36"><p>Asynchronous hardware-accelerated |
|
28 rendering and composition on devices on which dedicated graphics acceleration |
|
29 hardware is available. This is achieved through a Hardware Adaptation Layer |
|
30 (HAL). </p> </li> |
|
31 <li id="GUID-7CE7127E-873E-5284-A8DE-B2FF058E1107"><p>The ability to composit |
|
32 a semi-transparent UI buffer over highly dynamic content, such as OpenGL ES |
|
33 games, video and the camera viewfinder. </p> </li> |
|
34 <li id="GUID-3DAD6DFE-D2BE-5B7C-9253-38B7B30738D5"><p>The separation of control |
|
35 and data flow. This has advantages when running on non-uniform memory architectures |
|
36 and means that video decoding, UI rendering, and so on can take place and |
|
37 remain in the GPU memory domain. </p> </li> |
|
38 <li id="GUID-451CAB9D-DBB9-57FE-85C2-A8DE8C9D9436"><p>A foundation for secure |
|
39 screen content and Digital Rights Management (DRM). Applications no longer |
|
40 have direct access to the screen. Read and write access to the screen is controlled |
|
41 by the Window Server. </p> </li> |
|
42 <li id="GUID-060D7439-04FC-506A-B1B1-802C97F8931C"><p>Direct Screen Access |
|
43 (DSA) is supported in order to provide backwards compatibility. However, because |
|
44 in ScreenPlay the screen is no longer controlled by the Screen Driver, the |
|
45 DSA frame buffer is just another buffer that can be allocated dynamically |
|
46 on demand. ScreenPlay provides alternatives to DSA. </p> </li> |
|
47 </ul></section> |
|
48 <section id="GUID-D8BB0841-1E27-45A0-99AF-0F0A2D0A7362"><title>Architecture</title> <p>The |
|
49 following diagram shows the key components in the Symbian Foundation Graphics |
|
50 package and some closely related components in other packages. </p> <fig id="GUID-3300E986-4B93-5122-88C4-D7CC231F3BA3"> |
|
51 <title> Symbian^3 component architecture </title> |
|
52 <image href="GUID-DD22D66C-C303-5432-9C24-71F26190FCA0_d0e191110_href.png" placement="inline"/> |
|
53 </fig> <p>The key ScreenPlay components are introduced below under separate |
|
54 subheadings. </p> </section> |
|
55 <section id="GUID-AB1E3E20-01A9-4090-A404-0D1FF978AF53"><title>Graphics Composition </title><p>The |
|
56 composition engine composes content, possibly from several different sources, |
|
57 before it is displayed on the screen. Composition involves the important concepts |
|
58 of scene elements (or layers) and surfaces. Scene elements describe the geometric |
|
59 position, size and orientation of items to be displayed on the screen; whereas |
|
60 surfaces are pixel buffers for holding an image or part of a scene. </p> <p>The |
|
61 composition engine maintains the stack of scene elements and computes what |
|
62 is visible. For example, it culls invisible areas and maintains a list of |
|
63 dirty rectangles. It blends the pixels if necessary and can perform limited |
|
64 transformations, such as scaling and rotation (in 90° increments). The composition |
|
65 engine is an <b>adaptation component</b>, which means that device creators |
|
66 can adapt or replace it to suit the exact hardware on the device. The composition |
|
67 engine can utilize GPU hardware composition and LCD hardware rotation if they |
|
68 are available. </p> <p>The composition components are specific to ScreenPlay. |
|
69 For more information, see <xref href="GUID-859CAA08-59C9-5FD3-98DE-6BDD0D6ED50B.dita">Graphics |
|
70 Composition</xref>. </p></section> |
|
71 <section id="GUID-04973DCA-9DCA-40E8-AC4D-5FB244F23293"><title>Surface Manager |
|
72 and Surface Update Server</title><p>The Surface Manager component creates |
|
73 and manages graphics composition surfaces. The Surface Manager reference implementation |
|
74 implements surfaces as shared chunks because they must be accessible by user-side |
|
75 processes and the kernel and composition hardware. Surfaces can be multi-buffered |
|
76 and are identified by a 128 bit identifier (called the surface ID). This gets |
|
77 resolved to an actual memory address by calling the Surface Manager Map Surface |
|
78 API. Surfaces can be used by other Symbian components such as the <xref href="GUID-DDE1A8A9-1D67-53BF-8A65-340F139AD4AB.dita">Multimedia |
|
79 Framework (MMF)</xref> and <xref href="GUID-FC735256-6CB5-5EED-8E7D-42EFA039E6FD.dita">ECam |
|
80 viewfinder</xref> and by applications such as OpenGL ES games. The Surface |
|
81 Manager is an adaptation component and so can be adapted or replaced to suit |
|
82 the hardware. </p><p>The Surface Update component provides a communication |
|
83 mechanism between the composition engine and clients. This is particularly |
|
84 useful for clients (such as video) that produce fast updates and use multi-buffered |
|
85 surfaces. </p></section> |
|
86 <section id="GUID-92C609E2-EF56-460E-B4BD-B935AB8ECFFB"><title>Window Server</title><p>The |
|
87 Window Server has been extended with a render stage framework, which enables |
|
88 the last stage of the Window Server rendering to be customizable through render |
|
89 stage plug-ins. This process, known as "deferred rendering" is achieved by |
|
90 intercepting the output of the Window Server and then deciding how that output |
|
91 should be rendered. For example, the output can be hardware accelerated or |
|
92 it can be sent to a third party graphics engine. The render stage framework |
|
93 enables device creators to integrate different UIs and runtime environments |
|
94 (such as Flash or Silverlight) and to achieve transition effects such as slide, |
|
95 zoom and fade. </p><p>Symbian provides more than one render stage solution. |
|
96 The following diagram provides a simplified representation of one possible |
|
97 solution (called <i>solution A</i> in this topic). This solution is full featured. |
|
98 The diagram focuses on the more relevant components and does not attempt to |
|
99 show all components in the complete solution. This solution has a dependency |
|
100 on the S60 middleware layer, in particular on the Hitchcock component (which |
|
101 is in the UI Accelerator package). </p><fig id="GUID-0D91F9A6-68FC-5316-A16D-A3238F8452AD"> |
|
102 <title> Render stage solution A </title> |
|
103 <image href="GUID-643AFF2D-3EDB-5FAB-9631-7B93FABC56B6_d0e191164_href.png" placement="inline"/> |
|
104 </fig><p>Another possible solution (called <i>solution B</i>) is based on |
|
105 the DirectGDI and Graphics Resource components (which are described next), |
|
106 both of which have interface and adaptation layers. This solution is not full |
|
107 featured. Like the previous diagram, this diagram focuses on the more relevant |
|
108 components and does not attempt to show everything. </p><fig id="GUID-6A761DC5-1141-5515-BD03-09FBFE56F2D7"> |
|
109 <title>Render stage solution B</title> |
|
110 <image href="GUID-3DD37A41-E822-5CB6-A59E-0B309B5627D9_d0e191176_href.png" placement="inline"/> |
|
111 </fig><p>Both of these render stage solutions mean that existing Window Server |
|
112 applications can take advantage of hardware acceleration if it is available |
|
113 (and therefore run faster) without recompiling the code. </p><p>ScreenPlay |
|
114 provides extensions to the Window Server client-side API, which enable mobile |
|
115 devices to respond to events from a number of pointers, including their proximity |
|
116 and pressure. This feature is known as <xref href="GUID-A12A66ED-2C8F-5CE6-8F3E-332B045A35B4.dita">advanced |
|
117 pointers</xref>. </p><p>A new API, <xref href="GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9.dita#GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9/GUID-B431DC60-D11F-3239-8F52-4257B9B0E0C9"><apiname>RWsSession::Finish()</apiname></xref>, |
|
118 has been added to allow Window Server client applications to synchronize with |
|
119 the completion of Window Server rendering. The existing API, <xref href="GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9.dita#GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9/GUID-B83C6F44-1A3E-3959-910C-CBBF66C4A3D4"><apiname>RWsSession::Flush()</apiname></xref>, |
|
120 is redefined to simply flush the client-side command buffer, whereas previously |
|
121 it also provided a guarantee that Window Server had completed the command |
|
122 buffer’s operations. This behavioral change allows legacy clients to benefit |
|
123 from the asynchronous hardware rendering when supported by the render stage |
|
124 plug-in(s) that are in use. </p><p>For more information, see <xref href="GUID-57A777A3-5D67-5CBB-B224-B7AD422A451B.dita">Windowing |
|
125 Collection</xref>. </p></section> |
|
126 <section id="GUID-D67558F6-7841-487F-8F73-7580C2EFC026"><title>DirectGDI</title><p>DirectGDI |
|
127 provides a graphics context that can be hardware accelerated and allows an |
|
128 asynchronous interface. DirectGDI has two parts: a generic layer, which provides |
|
129 a client API and an adaptation layer. Device creators can replace the adaptation |
|
130 layer with an implementation that takes advantage of graphics accelerated |
|
131 hardware, if it is available, or a software implementation, if it is not available. </p><p>DirectGDI |
|
132 was introduced as a prototype in the development of ScreenPlay. It is deprecated |
|
133 in Symbian^3.</p></section> |
|
134 <section id="GUID-DF3BDD08-1C11-4FC6-BA4C-30CC13BE6005"><title>Graphics Resource</title><p>The |
|
135 Graphics Resource component provides an abstraction layer for the memory management |
|
136 of pixel and non-pixel data (such as OpenVG command lists). Like DirectGDI, |
|
137 it has a generic part, which provides a client API and an adaptation part, |
|
138 which device creators can adapt to take advantage of graphics hardware when |
|
139 it is available. </p><p>The Graphics Resource component was introduced as |
|
140 a prototype in the development of ScreenPlay. It is deprecated in Symbian^3 |
|
141 and will be removed in Symbian^4. However, a new Graphics Resource Interface |
|
142 component is planned for S^4. This new component will provide a similar but |
|
143 reduced API that is optimized for sharing images across processes.</p></section> |
|
144 <section id="GUID-35870066-DB83-477E-8532-002E1F91E9CF"><title>OpenVG, OpenGL |
|
145 ES and EGL</title><p>Symbian provides support for OpenVG, OpenGL ES and EGL. |
|
146 The main advantage of ScreenPlay with regard to EGL is that EGL can render |
|
147 into composition surfaces. For application developers this offers the ability |
|
148 to have semi-transparent GDI content on top of EGL content. The EGL client |
|
149 can query whether these new features are supported on the particular device. </p> <p>For |
|
150 more information, see <xref href="GUID-50254C2F-57B6-58C4-911F-294EF2B79C04.dita">Khronos |
|
151 API Support</xref>. </p></section> |
|
152 <section id="GUID-3B11D2F8-F3A4-4A2F-938A-B8EA0F64134A"><title>Screen Driver</title><p>In |
|
153 ScreenPlay, the implementation of the Screen Driver has been changed so that |
|
154 DSA content can be passed into the composition engine. </p></section> |
|
155 </conbody><related-links> |
|
156 <link href="GUID-859CAA08-59C9-5FD3-98DE-6BDD0D6ED50B.dita"><linktext>Graphics |
|
157 Composition</linktext></link> |
|
158 <link href="GUID-EF62BF88-3687-505D-8BD7-EEDF36246E56.dita"><linktext>Graphics |
|
159 Hardware Acceleration</linktext></link> |
|
160 <link href="GUID-99BC101A-9466-59EE-B5C9-7622BAF6E6FF.dita"><linktext>Graphics |
|
161 Concepts</linktext></link> |
|
162 |
|
163 |
|
164 |
|
165 |
|
166 </related-links></concept> |