--- a/Symbian3/PDK/Source/GUID-37393245-6AA1-528F-A5C1-EC114779791E.dita	Tue Jul 20 12:00:49 2010 +0100
+++ b/Symbian3/PDK/Source/GUID-37393245-6AA1-528F-A5C1-EC114779791E.dita	Fri Aug 13 16:47:46 2010 +0100
@@ -1,88 +1,88 @@
-<?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>
+<?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>
\ No newline at end of file