Symbian3/PDK/Source/GUID-F64E6551-670E-5E12-8103-DE504D3EC94F.dita
author Dominic Pinkman <Dominic.Pinkman@Nokia.com>
Thu, 11 Mar 2010 18:02:22 +0000
changeset 3 46218c8b8afa
parent 1 25a17d01db0c
child 5 f345bda72bc4
permissions -rw-r--r--
week 10 bug fix submission (SF PDK version): Bug 1892, Bug 1897, Bug 1319. Also 3 or 4 documents were found to contain code blocks with SFL, which has been fixed. Partial fix for broken links, links to Forum Nokia, and the 'Symbian platform' terminology issues.

<?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-F64E6551-670E-5E12-8103-DE504D3EC94F" xml:lang="en"><title>The
Non-ScreenPlay Graphics Architecture</title><shortdesc>ScreenPlay provides improved support for graphics hardware acceleration
and some other new features. However, it is possible to use the Symbian platform
without enabling ScreenPlay. This is called the non-ScreenPlay variant (sometimes
referred to as the <b>non-NGA</b> variant). This topic provides an introduction
to the graphics architecture when ScreenPlay is <b>not</b> enabled. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>The following diagram shows the non-ScreenPlay architecture. It includes
the components in the Graphics package and some closely related components
in other packages. </p>
<fig id="GUID-060B8747-36A8-5F2A-BE82-0F637381673A">
<title>The Symbian Foundation non-ScreenPlay graphics architecture </title>
<image href="GUID-1EC68F99-C383-5D3A-BAE9-52AF530F8445_d0e204008_href.png" placement="inline"/>
</fig>
<p>The software model is as follows: </p>
<ul>
<li id="GUID-8BDB2015-C8FD-51EC-AB19-A55C55DD6D4B"><p>The Hardware Adaptation
Layer (HAL) consists of the frame buffer and basic attributes. All processes
have equal access to the frame buffer and can both read and write to it. </p> </li>
<li id="GUID-06209922-9276-5843-95ED-CCE01A96A67C"><p>The Screen Driver provides
simple pixel, scan-line and bitmap operations. The Screen Driver has the same
interface for both bitmaps and the frame buffer. Hardware manufacturers can
adapt the Screen Driver to suit the available hardware. </p> </li>
<li id="GUID-333C52F6-5B6C-5212-8286-B344749550B5"><p>The BitGDI component
provides support for higher-level geometric primitives and text. The BitGDI
component is implemented in terms of Screen Driver operations. All BitGDI
rendering operations are synchronous. </p> </li>
<li id="GUID-B542796F-47AE-5B8A-976A-446315EC6550"><p>The Window Server multiplexes
access to the screen and provides a BitGDI-like interface. </p> </li>
<li id="GUID-81912D86-0CF6-5399-84FF-904E15BA8B50"><p>The Window Server provides
Direct Screen Access (DSA) support for applications that require high frame
rates (such as video and games) to bypass the Window Server and write to the
frame buffer directly. However, some interaction with the Window Server is
needed to prevent the application from drawing over other application's data. </p> </li>
</ul>
<p>In addition, the non-ScreenPlay architecture provides support for EGL,
OpenGL and OpenVG. </p>
<p>The following diagram shows the rendering stack in the non-ScreenPlay variant. </p>
<fig id="GUID-4A245007-BE0A-5DD6-A3D5-CAD9A16E0540">
<title>The rendering stack in the non-ScreenPlay variant</title>
<image href="GUID-A51AB0B8-A13D-52D0-BEF8-435F76B30941_d0e204053_href.png" placement="inline"/>
</fig>
<p>For the equivalent ScreenPlay diagram,
see <xref href="GUID-0DC3E5AA-1706-5255-ACD6-E7AB732E1095.dita">Graphics Composition
Collection Overview</xref>. </p>
<p>Although DSA provides a solution for applications that require high frame
rates, the non-ScreenPlay architecture has limitations when used on graphics
accelerated hardware and non-uniform memory models. The architecture may require
the copying of buffers between CPU and GPU memory as shown in the following
diagram. ScreenPlay provides a solution that requires less copying of buffers
in this type of use case. </p>
<fig id="GUID-0EAF51D1-173E-52E2-8E28-C5FB7F6F9BD0">
<title> Example non-uniform memory, non-ScreenPlay hardware model </title>
<image href="GUID-AB35BA46-87DB-59F0-9342-75550AD338B7_d0e204071_href.png" placement="inline"/>
</fig>
</conbody><related-links>
<link href="GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C.dita"><linktext>The ScreenPlay
Architecture</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>