<?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-37393245-6AA1-528F-A5C1-EC114779791E" xml:lang="en"><title>Screen
Driver Graphics Acceleration Support</title><shortdesc>This topic introduces the 2D graphics hardware acceleration support
provided by the Screen Driver component. This is generally used only in the
non-ScreenPlay variant, because ScreenPlay provides better alternatives for
implementing support for graphics acceleration hardware. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
<p> <b>Variant</b>: <xref href="GUID-F64E6551-670E-5E12-8103-DE504D3EC94F.dita">Non-ScreenPlay</xref>. <b>Target
audience</b>: Device creators </p>
<p>2D graphics acceleration enables improved performance for multimedia applications.
The Screen Driver component provides an API for hardware acceleration. This
is defined in <filepath>graphicsaccelerator.h</filepath> and is abstract.
The abstract base class for all accelerators is <xref href="GUID-26AD7E66-3C68-308D-9612-98438622FAC9.dita"><apiname>CGraphicsAccelerator</apiname></xref>.
The API also defines a set of common 2D graphics operations that are capable
of being accelerated in hardware (by a separate graphics processor), or in
software (by a DLL that optimizes the algorithms for particular devices and
display modes). The API may or may not be implemented by device creators. </p>
<p>Note that graphics acceleration, if implemented in the Screen Driver component,
is designed to be used transparently within <xref href="GUID-EAAD1719-C02C-5705-A5C3-993E36441BE6.dita">BitGDI</xref>,
not called explicitly by clients. </p>
<section><title>Architectural relationships</title> <p>The Screen Driver API
for 2D graphics hardware acceleration is closely related to the following: </p> <ul>
<li id="GUID-6BCB5C4E-1D79-5E40-9E5D-0AE96D9E2524"><p><xref href="GUID-B6D4AEE9-5C17-51D9-BBDE-7CCB5218279D.dita">GDI</xref>.
The graphics acceleration support that is provided by the Screen Driver component
is integrated into the underlying implementation of the GDI API. Applications
do not need to be aware of whether or not a particular graphics operation
is accelerated. If an accelerated implementation of a function is available,
it is used in preference to the generic algorithm. </p> </li>
<li id="GUID-A670E135-AAF3-55DB-A2F6-DF519B71A434"><p><xref href="GUID-EAAD1719-C02C-5705-A5C3-993E36441BE6.dita">BitGDI</xref>.
Software graphics accelerators can draw to standard bitmaps (the <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita"><apiname>CFbsBitmap</apiname></xref> class),
as well as hardware bitmaps (represented by the <xref href="GUID-DE8E21D9-FF93-358D-A479-F84435DBECAD.dita"><apiname>RHardwareBitmap</apiname></xref> class).
However, hardware graphics accelerators can only draw to hardware bitmaps. </p> </li>
</ul> </section>
<section><title>Description</title> <p>Each class derived from <xref href="GUID-B741084F-D353-3298-9F97-2F93DF5B2CE3.dita"><apiname>TGraphicsOperation</apiname></xref> represents
a different accelerated graphics operation. The subset of these operations
supported by an accelerator is hardware-dependent and varies from device to
device. The graphics accelerator's capabilities can be queried before it is
used. The <xref href="GUID-EAA3593A-95E4-33BC-A43D-AC1E9E354245.dita"><apiname>TGraphicsAcceleratorCaps</apiname></xref> class gives some of
the capabilities, for instance whether mask bitmaps must be in a certain display
mode. To find out whether a particular operation is supported, an attempt
should be made to execute it. Unsupported functions should simply return <codeph>KErrNotSupported</codeph>.
The user of the API does not need to be aware of whether an operation is accelerated
in hardware or in software—the API is the same for both. </p> <p>The types
of accelerated operations that are enabled by this API include: </p> <ul>
<li id="GUID-BB4A305D-5EA2-56B9-8F9E-78F6A8669CAA"><p>filling a rectangle
with a color or pattern; fading and inverting colors </p> </li>
<li id="GUID-6A4EDF8C-6C0F-52A8-98F0-F26083A4A2F1"><p>a variety of bitblt
operations, including using a mask, transparency or alpha blending. These
operations may involve scaling the bitmap </p> </li>
<li id="GUID-4F5086F2-1886-5E1D-87F1-30106EC7C82F"><p>filling a polygon with
a color or a pattern. </p> </li>
</ul> <p>All of these operations may optionally take place within a clipping
region. </p> <p>Hardware graphics acceleration can only draw to hardware bitmaps.
These are bitmaps that are stored in a static, contiguous area of physical
memory that is accessible to both the CPU and a separate graphics processor.
The interface to a hardware bitmap is the class <xref href="GUID-DE8E21D9-FF93-358D-A479-F84435DBECAD.dita"><apiname>RHardwareBitmap</apiname></xref>.
Software graphics acceleration can write to both <codeph>CFbsBitmap</codeph> s
and <codeph>RHardwareBitmap</codeph> s. </p> </section>
<section><title>Limitations</title> <p>The Screen Driver provides a synchronous
API for the implementation of hardware acceleration. This means that although
each operation may execute faster than within a software implementation, the
calling thread on the CPU must wait for each GPU operation to complete. This
can cause significant delay within the context of the Window Server. In addition,
graphics acceleration hardware is generally designed to accept a pipeline
of instructions rather than the individual instructions provided by the Screen
Driver. The Screen Driver's one-by-one approach causes greater latency than
could be achieved using a pipeline approach. These limitations are part of
the rationale for the introduction of the <xref href="GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C.dita">ScreenPlay
architecture</xref>. </p> </section>
</conbody><related-links>
<link href="GUID-F64E6551-670E-5E12-8103-DE504D3EC94F.dita"><linktext>The Non-ScreenPlay
Architecture</linktext></link>
<link href="GUID-9E7D563E-9FFB-5FA9-8944-9CBAC281FDD2.dita"><linktext>Screen Driver
Component</linktext></link>
<link href="GUID-E9FF94D2-AFFD-54A4-A6C2-00929BC70DB0.dita"><linktext>BitGDI Concepts</linktext>
</link>
<link href="GUID-0AB9B221-38AE-576E-AC5A-C4C106E3D93B.dita"><linktext>GDI Overview</linktext>
</link>
</related-links></concept>