<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C" xml:lang="en"><title>The
ScreenPlay Graphics Architecture</title><shortdesc>This topic provides an introduction to ScreenPlay and its architecture.
ScreenPlay is a new graphics architecture, introduced in Symbian^3 (S^3).
ScreenPlay enables device creators to take advantage of improved software
performance, hardware acceleration and third party graphics engines. ScreenPlay
is sometimes known as the <b>New Graphics Architecture (NGA)</b>. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>ScreenPlay is a response to new requirements and developments in device
hardware models. For example, ScreenPlay can support graphics accelerators
and graphics processing units (GPUs) and non-uniform memory models as well
as uniform memory models. A non-uniform memory model is an architecture in
which a GPU has a completely different processing area from the CPU such that
the GPU memory is not available to the CPU and vice versa. ScreenPlay can
handle non-uniform memory models without the need to copy buffers between
the different processing areas. </p>
<section id="GUID-D4071308-2FA1-4B04-9AC2-926E1D619D08"><title>Key features</title><ul>
<li id="GUID-0325A4C9-BAA3-5FA3-8389-BB406C020F36"><p>Asynchronous hardware-accelerated
rendering and composition on devices on which dedicated graphics acceleration
hardware is available. This is achieved through a Hardware Adaptation Layer
(HAL). </p> </li>
<li id="GUID-7CE7127E-873E-5284-A8DE-B2FF058E1107"><p>The ability to composit
a semi-transparent UI buffer over highly dynamic content, such as OpenGL ES
games, video and the camera viewfinder. </p> </li>
<li id="GUID-3DAD6DFE-D2BE-5B7C-9253-38B7B30738D5"><p>The separation of control
and data flow. This has advantages when running on non-uniform memory architectures
and means that video decoding, UI rendering, and so on can take place and
remain in the GPU memory domain. </p> </li>
<li id="GUID-451CAB9D-DBB9-57FE-85C2-A8DE8C9D9436"><p>A foundation for secure
screen content and Digital Rights Management (DRM). Applications no longer
have direct access to the screen. Read and write access to the screen is controlled
by the Window Server. </p> </li>
<li id="GUID-060D7439-04FC-506A-B1B1-802C97F8931C"><p>Direct Screen Access
(DSA) is supported in order to provide backwards compatibility. However, because
in ScreenPlay the screen is no longer controlled by the Screen Driver, the
DSA frame buffer is just another buffer that can be allocated dynamically
on demand. ScreenPlay provides alternatives to DSA. </p> </li>
</ul></section>
<section id="GUID-D8BB0841-1E27-45A0-99AF-0F0A2D0A7362"><title>Architecture</title> <p>The
following diagram shows the key components in the Symbian Foundation Graphics
package and some closely related components in other packages. </p> <fig id="GUID-3300E986-4B93-5122-88C4-D7CC231F3BA3">
<title>             Symbian^3 component architecture            </title>
<image href="GUID-DD22D66C-C303-5432-9C24-71F26190FCA0_d0e184514_href.png" placement="inline"/>
</fig> <p>The key ScreenPlay components are introduced below under separate
subheadings. </p> </section>
<section id="GUID-AB1E3E20-01A9-4090-A404-0D1FF978AF53"><title>Graphics Composition </title><p>The
composition engine composes content, possibly from several different sources,
before it is displayed on the screen. Composition involves the important concepts
of scene elements (or layers) and surfaces. Scene elements describe the geometric
position, size and orientation of items to be displayed on the screen; whereas
surfaces are pixel buffers for holding an image or part of a scene. </p> <p>The
composition engine maintains the stack of scene elements and computes what
is visible. For example, it culls invisible areas and maintains a list of
dirty rectangles. It blends the pixels if necessary and can perform limited
transformations, such as scaling and rotation (in 90° increments). The composition
engine is an <b>adaptation component</b>, which means that device creators
can adapt or replace it to suit the exact hardware on the device. The composition
engine can utilize GPU hardware composition and LCD hardware rotation if they
are available. </p> <p>The composition components are specific to ScreenPlay.
For more information, see <xref href="GUID-859CAA08-59C9-5FD3-98DE-6BDD0D6ED50B.dita">Graphics
Composition</xref>. </p></section>
<section id="GUID-04973DCA-9DCA-40E8-AC4D-5FB244F23293"><title>Surface Manager
and Surface Update Server</title><p>The Surface Manager component creates
and manages graphics composition surfaces. The Surface Manager reference implementation
implements surfaces as shared chunks because they must be accessible by user-side
processes and the kernel and composition hardware. Surfaces can be multi-buffered
and are identified by a 128 bit identifier (called the surface ID). This gets
resolved to an actual memory address by calling the Surface Manager Map Surface
API. Surfaces can be used by other Symbian components such as the <xref href="GUID-DDE1A8A9-1D67-53BF-8A65-340F139AD4AB.dita">Multimedia
Framework (MMF)</xref> and <xref href="GUID-FC735256-6CB5-5EED-8E7D-42EFA039E6FD.dita">ECam
viewfinder</xref> and by applications such as OpenGL ES games. The Surface
Manager is an adaptation component and so can be adapted or replaced to suit
the hardware. </p><p>The Surface Update component provides a communication
mechanism between the composition engine and clients. This is particularly
useful for clients (such as video) that produce fast updates and use multi-buffered
surfaces. </p></section>
<section id="GUID-92C609E2-EF56-460E-B4BD-B935AB8ECFFB"><title>Window Server</title><p>The
Window Server has been extended with a render stage framework, which enables
the last stage of the Window Server rendering to be customizable through render
stage plug-ins. This process, known as "deferred rendering" is achieved by
intercepting the output of the Window Server and then deciding how that output
should be rendered. For example, the output can be hardware accelerated or
it can be sent to a third party graphics engine. The render stage framework
enables device creators to integrate different UIs and runtime environments
(such as Flash or Silverlight) and to achieve transition effects such as slide,
zoom and fade. </p><p>Symbian provides more than one render stage solution.
The following diagram provides a simplified representation of one possible
solution (called <i>solution A</i> in this topic). This solution is full featured.
The diagram focuses on the more relevant components and does not attempt to
show all components in the complete solution. This solution has a dependency
on the S60 middleware layer, in particular on the Hitchcock component (which
is in the UI Accelerator package). </p><fig id="GUID-0D91F9A6-68FC-5316-A16D-A3238F8452AD">
<title>            Render stage solution A            </title>
<image href="GUID-643AFF2D-3EDB-5FAB-9631-7B93FABC56B6_d0e184568_href.png" placement="inline"/>
</fig><p>Another possible solution (called <i>solution B</i>) is based on
the DirectGDI and Graphics Resource components (which are described next),
both of which have interface and adaptation layers. This solution is not full
featured. Like the previous diagram, this diagram focuses on the more relevant
components and does not attempt to show everything. </p><fig id="GUID-6A761DC5-1141-5515-BD03-09FBFE56F2D7">
<title>Render stage solution B</title>
<image href="GUID-3DD37A41-E822-5CB6-A59E-0B309B5627D9_d0e184580_href.png" placement="inline"/>
</fig><p>Both of these render stage solutions mean that existing Window Server
applications can take advantage of hardware acceleration if it is available
(and therefore run faster) without recompiling the code. </p><p>ScreenPlay
provides extensions to the Window Server client-side API, which enable mobile
devices to respond to events from a number of pointers, including their proximity
and pressure. This feature is known as <xref href="GUID-A12A66ED-2C8F-5CE6-8F3E-332B045A35B4.dita">advanced
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>,
has been added to allow Window Server client applications to synchronize with
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>,
is redefined to simply flush the client-side command buffer, whereas previously
it also provided a guarantee that Window Server had completed the command
buffer’s operations. This behavioral change allows legacy clients to benefit
from the asynchronous hardware rendering when supported by the render stage
plug-in(s) that are in use. </p><p>For more information, see <xref href="GUID-57A777A3-5D67-5CBB-B224-B7AD422A451B.dita">Windowing
Collection</xref>. </p></section>
<section id="GUID-D67558F6-7841-487F-8F73-7580C2EFC026"><title>DirectGDI</title><p>DirectGDI
provides a graphics context that can be hardware accelerated and allows an
asynchronous interface. DirectGDI has two parts: a generic layer, which provides
a client API and an adaptation layer. Device creators can replace the adaptation
layer with an implementation that takes advantage of graphics accelerated
hardware, if it is available, or a software implementation, if it is not available. </p><p>DirectGDI
was introduced as a prototype in the development of ScreenPlay. It is deprecated
in Symbian^3.</p></section>
<section id="GUID-DF3BDD08-1C11-4FC6-BA4C-30CC13BE6005"><title>Graphics Resource</title><p>The
Graphics Resource component provides an abstraction layer for the memory management
of pixel and non-pixel data (such as OpenVG command lists). Like DirectGDI,
it has a generic part, which provides a client API and an adaptation part,
which device creators can adapt to take advantage of graphics hardware when
it is available. </p><p>The Graphics Resource component was introduced as
a prototype in the development of ScreenPlay. It is deprecated in Symbian^3
and will be removed in Symbian^4.  However, a new Graphics Resource Interface
component is planned for S^4. This new component will provide a similar but
reduced API that is optimized for sharing images across processes.</p></section>
<section id="GUID-35870066-DB83-477E-8532-002E1F91E9CF"><title>OpenVG, OpenGL
ES and EGL</title><p>Symbian provides support for OpenVG, OpenGL ES and EGL.
The main advantage of ScreenPlay with regard to EGL is that EGL can render
into composition surfaces. For application developers this offers the ability
to have semi-transparent GDI content on top of EGL content. The EGL client
can query whether these new features are supported on the particular device. </p> <p>For
more information, see <xref href="GUID-50254C2F-57B6-58C4-911F-294EF2B79C04.dita">Khronos
API Support</xref>. </p></section>
<section id="GUID-3B11D2F8-F3A4-4A2F-938A-B8EA0F64134A"><title>Screen Driver</title><p>In
ScreenPlay, the implementation of the Screen Driver has been changed so that
DSA content can be passed into the composition engine. </p></section>
</conbody><related-links>
<link href="GUID-859CAA08-59C9-5FD3-98DE-6BDD0D6ED50B.dita"><linktext>Graphics
Composition</linktext></link>
<link href="GUID-EF62BF88-3687-505D-8BD7-EEDF36246E56.dita"><linktext>Graphics
Hardware Acceleration</linktext></link>
<link href="GUID-99BC101A-9466-59EE-B5C9-7622BAF6E6FF.dita"><linktext>Graphics
Concepts</linktext></link>




</related-links></concept>