Symbian3/SDK/Source/GUID-EF62BF88-3687-505D-8BD7-EEDF36246E56.dita
author Dominic Pinkman <dominic.pinkman@nokia.com>
Tue, 20 Jul 2010 12:00:49 +0100
changeset 13 48780e181b38
parent 0 89d6a7a84779
permissions -rw-r--r--
Week 28 contribution of SDK documentation content. See release notes for details. Fixes bugs Bug 1897 and Bug 1522.

<?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>OpenGLES Implementation</entry>
<entry>OpenGLES Implementation</entry>
</row>
<row>
<entry>OpenVG Implementation</entry>
<entry>OpenVG Implementation</entry>
</row>
<row>
<entry>EGL Implementation</entry>
<entry>EGL Implementation </entry>
</row>
<row>
<entry>Screen Driver</entry>
<entry>Screen Driver</entry>
</row>
<row>
<entry>Extended Bitmap Rasterizer Plug-in</entry>
<entry>Extended Bitmap Rasterizer Plug-in </entry>
</row>
<row>
<entry>DirectGDI Adaptation </entry>
<entry/>
</row>
<row>
<entry>Graphics Resource Adaptation </entry>
<entry/>
</row>

<row>
<entry>OpenWF Composition Engine</entry>
<entry/>
</row>
<row>
<entry>Surface Manager</entry>
<entry/>
</row>
<row>
<entry>Surface Update </entry>
<entry/>
</row>
<row>
<entry>Render Stages* </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>