Symbian3/PDK/Source/GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C.dita
changeset 1 25a17d01db0c
child 3 46218c8b8afa
equal deleted inserted replaced
0:89d6a7a84779 1:25a17d01db0c
       
     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_d0e203609_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_d0e203663_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_d0e203675_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 <link href="GUID-C7B420DE-CEDA-5D3F-8095-71136E862CDF.dita">
       
   163 <linktext>Surface Manager Component</linktext></link>
       
   164 <link href="GUID-81A0A2E9-4BB9-58BF-B2D3-08098E7E9C7C.dita">
       
   165 <linktext>Surface Update Component</linktext></link>
       
   166 <link href="GUID-63CB6C7E-44EC-5D0B-A37D-FE78F7D76592.dita">
       
   167 <linktext>Graphics Composition Collection</linktext></link>
       
   168 <link href="GUID-3A2785D4-6185-50C3-8D7E-5D94CD2B7C98.dita">
       
   169 <linktext>Render Stages</linktext></link>
       
   170 </related-links></concept>