<?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-CD4B8ECA-AFE7-593C-B095-5D642EA2EC61" xml:lang="en"><title>DirectGDI

Component Overview</title><shortdesc>This topic provides an introduction to the DirectGDI component.

DirectGDI provides a graphics context that can be hardware accelerated, and

allows an asynchronous interface. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p><b>Target audience</b>: Device creators. </p>

<note type="note">DirectGDI is deprecated in Symbian^3.</note>

<p>The DirectGDI framework has two parts: a generic layer, which provides

a client API and an adaptation layer. Device creators can replace the adaptation

layer with an implementation that takes advantage of graphics accelerated

hardware, if it is available, or a software implementation, if it is not available.

This section covers the generic layer. </p>

<p>Window Server rendering is performed by one or more <xref href="GUID-3A2785D4-6185-50C3-8D7E-5D94CD2B7C98.dita">render

stage plug-ins</xref>, which device creators can also replace. In ScreenPlay,

the Symbian render stage plug-in uses DirectGDI rather than the older BitGDI

component. This means that existing Window Server applications can potentially

take advantage of hardware acceleration (and therefore run faster) without

recompiling the code. </p>

<p>The following diagram shows the usage of the DirectGDI component. In this

diagram the application is a regular GUI application that draws using the

Symbian Window Server API. </p>

<fig id="GUID-E0731CEB-BA28-5F07-8584-16286D439433">

<title> Usage of DirectGDI          </title>

</fig>

<p>The Symbian DirectGDI adaptation uses the <xref href="GUID-82B0B4B9-6BC2-5BEF-B3B0-D57AC57F8D8A.dita">Graphics

Resource component</xref>, which provides an abstraction layer for the memory

management of pixel and non-pixel data (such as a list of VG commands). The

Graphics Resource component supports uniform and non-uniform memory architectures,

but is not available on all platforms. Like DirectGDI, the Graphics Resource

component has generic and adaptation layers. When it is available, device

creators can tailor the adaptation for a specific graphics hardware accelerator.

The Symbian reference Graphics Resource adaptation uses surfaces. </p>

<section id="GUID-EB8CE781-DA66-4557-87D1-88B0AF97F7B7"><title>Key concepts

and terms</title> <p>The key elements of DirectGDI are driver, resources and

drawing context as shown in the following diagram. </p> <fig id="GUID-13399385-2DC4-50A2-8DC7-5712BC5325A7">

<title> DirectGDI key elements            </title>

</fig> <p> <b>Driver</b>. The driver class <xref href="GUID-0C7CD826-95FD-3DD2-9394-3A20316C9C61.dita"><apiname>CDirectGdiDriver</apiname></xref> implements

platform-specific functionality to create and manage device-dependent drawing

contexts and resources. It defines the Hardware Adaptation Interface (HAI)

that must be implemented by device creators. </p> <p> <b>Drawing Context</b>. <xref href="GUID-09AFDE10-489E-3215-B821-DE7B2D31A007.dita"><apiname>CDirectGdiContext</apiname></xref> represents

a new drawing context that is similar to <xref href="GUID-4A501086-7EFF-376D-8901-6D9B2EB4EFF2.dita"><apiname>CFbsBitGc</apiname></xref> and <xref href="GUID-B782C9A1-D7CB-3BD7-8167-27F5E3F00CB0.dita"><apiname>CWindowsGc</apiname></xref>,

but without functions (such as read-modify-write functions like <codeph>SetFaded()</codeph>)

that are not suitable for hardware acceleration. <xref href="GUID-09AFDE10-489E-3215-B821-DE7B2D31A007.dita"><apiname>CDirectGdiContext</apiname></xref> also

provides new rendering operations that are not available via <xref href="GUID-4A501086-7EFF-376D-8901-6D9B2EB4EFF2.dita"><apiname>CFbsBitGc</apiname></xref>,

such as drawing contents generated using non-native APIs. </p> <p> <b>Resources</b>.

DirectGDI introduces two new abstractions of graphics resources: <xref href="GUID-66A0A534-7BB6-304F-9A5E-17A125DA916F.dita"><apiname>RDirectGdiDrawableSource</apiname></xref> and <xref href="GUID-8F7C2E3C-3DF6-3C76-85C0-04922A99E9D0.dita"><apiname>RDirectGdiImageTarget</apiname></xref>. These resources are created by binding them to the <xref href="GUID-6F23F34A-A0BE-349C-ADE7-61A5AEF48018.dita"><apiname>RSgDrawable</apiname></xref> or <xref href="GUID-EDC0E03F-37F6-3BEC-8FF3-D03C3CDB949C.dita"><apiname>RSgImage</apiname></xref> resource

defined in the <xref href="GUID-82B0B4B9-6BC2-5BEF-B3B0-D57AC57F8D8A.dita">Graphics

Resource component</xref>. </p> <p> </p> </section>

<section id="GUID-F7EFEDD5-B145-46EB-BEF1-4FD84F6753BA"><title>Architectural

relationships</title> <p>The DirectGDI component provides a framework that

enables graphics hardware acceleration and interleaved rendering. This framework

provides an API for client applications and a Hardware Adaptation Interface

(HAI), which defines interfaces that must be implemented by device and hardware

manufacturers in order to provide the API functionality. The framework has

a dependency on the <xref href="GUID-82B0B4B9-6BC2-5BEF-B3B0-D57AC57F8D8A.dita">Graphics

Resource component</xref>. </p> <p>The Graphics package provides two DirectGDI

adaptations: </p> <ul>

<li id="GUID-C34EF67E-127F-5464-AEA2-01F8FBD482CF"><p>a purely software adaptation

that uses existing components to draw to the screen in a similar manner to

BitGDI </p> </li>

<li id="GUID-F80A29B5-E6BE-5190-8CD6-877CA0341745"><p>a hardware adaptation

that uses OpenVG and EGL APIs. </p> </li>

</ul> <p>The following figure shows how the DirectGDI generic layer and the

reference adaptations interface with each other. It shows how the software

and hardware adaptations use the same HAI. However, only one adaptation can

be present on a phone. </p> <fig id="GUID-DCD69302-90C3-5C1B-BC62-E901EDBE133B">

<title> DirectGDI architecture            </title>

</fig> <p>For more information about the DirectGDI adaptation layer, see the <xref href="GUID-22E46647-D677-5A47-A7E0-E1E0AE736B27.dita">DirectGDI Adaptation Overview</xref>. </p> </section>

<section id="GUID-21429397-2B36-4799-869F-5948C282B4A0"><title>DLL summary</title> <p>DirectGDI

consists of one DLL, <filepath>directgdi.dll</filepath>. For more information,

see <xref href="GUID-936A024F-FFBA-530E-A2C6-C835B71633F7.dita">DirectGDI Library </xref>. </p> </section>

<section id="GUID-C8B5A833-6687-4198-A57B-81BE433DE7E7"><title>Main usage</title> <p>The

main usage of DirectGDI is within a Window Server <xref href="GUID-3A2785D4-6185-50C3-8D7E-5D94CD2B7C98.dita">render

stage plug-in</xref>. This enables the Window Server rendering to be hardware

accelerated when suitable hardware is available. Currently DirectGDI is not

available for use by applications. </p> </section>

</conbody><related-links>

<link href="GUID-936A024F-FFBA-530E-A2C6-C835B71633F7.dita"><linktext>DirectGDI

Library Overview</linktext></link>

<link href="GUID-E2A886E1-39FD-517F-870E-3B1BCD49E8CD.dita"><linktext>Off-Screen

Rendering with                 DirectGDI Tutorial</linktext></link>

<link href="GUID-E9C6DBBF-1910-595D-94A1-67664CF7B7A6.dita"><linktext>DirectGDI

Interface Component</linktext></link>

</related-links></concept>