<?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_d0e162344_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_d0e162398_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_d0e162410_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>