--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-EF62BF88-3687-505D-8BD7-EEDF36246E56.dita	Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,132 @@
+<?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>
\ No newline at end of file