Symbian3/SDK/Source/GUID-F64E6551-670E-5E12-8103-DE504D3EC94F.dita
author Dominic Pinkman <dominic.pinkman@nokia.com>
Fri, 11 Jun 2010 12:39:03 +0100
changeset 8 ae94777fff8f
parent 7 51a74ef9ed63
child 13 48780e181b38
permissions -rw-r--r--
Week 23 contribution of SDK documentation content. See release notes for details. Fixes bugs Bug 2714, Bug 462.

<?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_d0e184889_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_d0e184934_href.png" placement="inline"/>
</fig>

<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_d0e184946_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>