<?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-EF62BF88-3687-505D-8BD7-EEDF36246E56" xml:lang="en"><title>Graphics

Hardware Acceleration</title><shortdesc>This topic describes some of the issues surrounding the use of

graphics hardware to improve graphics performance. It also provides a summary

of the components that device creators need to adapt to take advantage of

graphics hardware. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<section><title>Background</title> <p><b>Graphics acceleration hardware </b> </p> <p>A

graphics accelerator or Graphics Processing Unit (GPU) is a dedicated hardware

processor that works in parallel with the main processor (CPU). By relieving

the CPU of highly intensive graphics processing, a GPU makes it is possible

to achieve sophisticated screen displays (such as video, animated graphics

and 3D games) without compromising other aspects of performance. </p> <p><b>Animations </b> </p> <p>Animation

involves transferring and manipulating large amounts of data (stored as bitmaps

or instructions) from one area of memory and putting them into another (the

screen buffer). Frame rates may be between 10 and 30 frames per second (depending

on requirements and sources). </p> <p><b>Composition </b> </p> <p>Manufacturers

of smartphones face the complexity of displaying on the screen a mixture of

different types of content, such as streaming video, the camera viewfinder

and regular UI elements with animated icons. These different types of content

come from different places—such as multimedia sources (streaming video), camera

hardware, the Window Server and EGL (3D and vector graphics). The different

types of content are displayed in different areas of the screen and are updated

by different processes. The graphics system must be capable not only of creating

sophisticated graphical output from each source simultaneously but also of

composing (compositing) them at up to 30 frames per second. For an introduction

to how ScreenPlay handles this challenge, see <xref href="GUID-859CAA08-59C9-5FD3-98DE-6BDD0D6ED50B.dita">Graphics

Composition</xref>. </p> <p><b>Optimization </b> </p> <p>GPUs work best when

they do so uninterrupted. They usually have a 'long processing pipe' (a lot

of data cached in memory) and flushing it or allowing it to empty reduces

effectiveness. This can be avoided by avoiding the following: </p> <ul>

<li id="GUID-827CF5E4-86EE-5766-BAF4-395205461FF0"><p> <b>Context switching</b>.

The working data (such as color information, vertex positions, transformations

and textures) is known as the <i>context</i>. If more than one application

wants to use the processor at the same time, the processor must swap between

them. This involves the processor saving the context from one application,

flushing its buffers, and loading the context from the next. Context switching

is time consuming and disruptive. </p> </li>

<li id="GUID-5C98575F-A0EA-5B9F-ACCC-C7A0D2B93058"><p> <b>Copying and reformatting

data</b>. Changing the format and copying pixel data involves time and memory.

If the GPU and CPU cannot share memory and data formats, much time, processing

power and memory is required to copy and convert data. </p> </li>

</ul> <p>ScreenPlay avoids context switching and reformatting and copying

data wherever possible. </p> <p><b>Hardware variety </b> </p> <p>The combination

of hardware acceleration, animation and composition would be a substantial

challenge in a fixed, dedicated hardware architecture. The Symbian platform,

however, is designed to operate on a variety of hardware architectures, only

some of which are capable of graphics acceleration and processing. The Symbian

graphics subsystem can be customized to take advantage of a variety graphics

processing hardware. Customization is via 'back end' components which do not

affect the public API. </p> </section>

<section><title>The hardware adaptation components</title> <p>Here we provide

information about which graphics components device creators can adapt or replace.

Components that can be adapted or replaced to suit the hardware are generally

called <i>adaptations</i>. Adaptable and replaceable components that do not

depend on the hardware are called <i>customizations</i> and are indicated

by an asterisk (*) in the following table. </p> <p>The details vary depending

on whether the <xref href="GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C.dita">ScreenPlay</xref> or <xref href="GUID-F64E6551-670E-5E12-8103-DE504D3EC94F.dita">non-ScreenPlay</xref> variant

is in use. </p> <table id="GUID-C401C8AE-7EE2-5B8F-9B17-B8C2E5E6B5B6">

<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>

<thead>

<row>

<entry>ScreenPlay</entry>

<entry>Non-ScreenPlay</entry>

</row>

</thead>

<tbody>

<row>

<entry><xref href="GUID-04D917A1-E1A0-5149-9660-80A1146D0984.dita">OpenGLES Implementation</xref> </entry>

<entry><xref href="GUID-04D917A1-E1A0-5149-9660-80A1146D0984.dita">OpenGLES Implementation</xref> </entry>

</row>

<row>

<entry><xref href="GUID-1A8ED0EB-B3B7-553F-95E3-2120D877966B.dita">OpenVG Implementation</xref></entry>

<entry><xref href="GUID-1A8ED0EB-B3B7-553F-95E3-2120D877966B.dita">OpenVG Implementation</xref> </entry>

</row>

<row>

<entry><xref href="GUID-DC8BFEF5-DA50-52DA-8CE2-5729A4A005F6.dita">EGL Implementation</xref> </entry>

<entry><xref href="GUID-DC8BFEF5-DA50-52DA-8CE2-5729A4A005F6.dita">EGL Implementation</xref> </entry>

</row>

<row>

<entry><xref href="GUID-9E7D563E-9FFB-5FA9-8944-9CBAC281FDD2.dita">Screen Driver</xref> </entry>

<entry><xref href="GUID-9E7D563E-9FFB-5FA9-8944-9CBAC281FDD2.dita">Screen Driver</xref> </entry>

</row>

<row>

<entry><xref href="GUID-D76C7759-739D-5C98-B718-7297687FE630.dita">Extended Bitmap

Rasterizer Plug-in</xref> </entry>

<entry><xref href="GUID-D76C7759-739D-5C98-B718-7297687FE630.dita">Extended Bitmap

Rasterizer Plug-in</xref> </entry>

</row>

<row>

<entry><xref href="GUID-BB4F5388-32EA-5A2E-845D-E5339D2040E9.dita">DirectGDI Adaptation</xref> </entry>

<entry/>

</row>

<row>

<entry><xref href="GUID-5E46C0EE-BD7D-5C85-8083-575BB2888AA7.dita">Graphics Resource

Adaptation</xref> </entry>

<entry/>

</row>

<row>

<entry><xref href="GUID-8BEE0411-C6E9-5840-BE22-EC271A4D97DD.dita">OpenWF Composition

Engine</xref></entry>

<entry/>

</row>

<row>

<entry><xref href="GUID-C7B420DE-CEDA-5D3F-8095-71136E862CDF.dita">Surface Manager</xref>  </entry>

<entry/>

</row>

<row>

<entry><xref href="GUID-8E8FE99A-5F4D-5B0F-87AB-A58EB4BEB6E9.dita">Surface Update</xref> </entry>

<entry/>

</row>

<row>

<entry><xref href="GUID-3A2785D4-6185-50C3-8D7E-5D94CD2B7C98.dita">Render Stages</xref>* </entry>

<entry/>

</row>

</tbody>

</tgroup>

</table> </section>

</conbody><related-links>

<link href="GUID-99BC101A-9466-59EE-B5C9-7622BAF6E6FF.dita"><linktext>Graphics

Concepts</linktext></link>

<link href="GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C.dita"><linktext>The ScreenPlay

Architecture</linktext></link>

<link href="GUID-F64E6551-670E-5E12-8103-DE504D3EC94F.dita"><linktext>The Non-ScreenPlay

Architecture</linktext></link>

</related-links></concept>