<?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-11BC2AAA-FDB8-5600-8488-F27A9552E336" xml:lang="en"><title>Render

Stage Interfaces</title><shortdesc>This topic builds on the Render Stages Overview and provides an

introduction to the main render stage interfaces. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p> <b>Variant</b>: <xref href="GUID-D93978BE-11A3-5CE3-B110-1DEAA5AD566C.dita">ScreenPlay</xref>. <b>Target

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

<p>The <xref href="GUID-2E8929E6-9555-51D2-B41D-6F1D05A4DB87.dita">Render Stages

Overview</xref> introduced some of the interfaces that render stages implement.

Here we will look at those in more detail, along with some of the other interfaces. </p>

<section><title>MWsObjectProvider</title> <p> <xref href="GUID-A47A4139-70FD-3F76-B51E-0452A0F6A76F.dita"><apiname>MWsObjectProvider</apiname></xref> is

a Window Server plug-in framework interface, which provides a mechanism through

which classes can offer extension interfaces. Render stages and most of the

related classes implement this interface. </p> </section>

<section><title>CWsRenderStage</title> <p> <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita"><apiname>CWsRenderStage</apiname></xref> is

an abstract class that all render stages must derive from. It has two pure

virtual functions: <codeph>Begin()</codeph> and <codeph>End()</codeph>, which

must be implemented in the concrete class. </p> <p>The Window Server's output

to the render stage pipeline is not a continuous stream, but instead consists

of batches of drawing operations. When client drawing or server-side animations

require a screen update, the <xref href="GUID-22093E74-EFE7-5642-93DE-1573E18F7C08.dita">Window

Server rendering loop</xref> schedules a redraw. When this redraw occurs,

a batch of drawing operations is produced to perform the updates. </p> <p>The

Window Server calls <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita#GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A/GUID-75503F6F-91DA-3392-8CD5-34FFF9095D30"><apiname>CWsRenderStage::Begin()</apiname></xref> at the beginning

of a batch of draw operations. This gives the render stages an opportunity

to perform any preparation. Similarly the Window Server calls <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita#GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A/GUID-0EBA06BF-D17F-3485-85B6-F4B855A48B62"><apiname>CWsRenderStage::End()</apiname></xref> at

the end of the batch, which provides the render stages with the opportunity

to perform any tidying up. </p> <p>For example, a flicker buffer render stage

might use the <codeph>Begin()</codeph> call as a signal to clear its off-screen

buffer, and the <codeph>End()</codeph> call as a signal to perform the blit

of the accumulated updates to the next render stage. The final render stage

might use the <codeph>End()</codeph> call as the signal to submit a surface

update to the composition engine. </p> <p>Render stages perform all rendering

operations between the <codeph>Begin()</codeph> and <codeph>End()</codeph> calls.

The Window Server calls the <xref href="GUID-44844998-D8BF-3F2F-9BA2-FB9BB497F8C0.dita"><apiname>MWsGraphicsContext</apiname></xref> functions

only between the <codeph>Begin()</codeph> and <codeph>End()</codeph> calls.

The render stage could <codeph>ASSERT</codeph> that these functions are not

called at other times and ignore them if they are or take some other action

as appropriate. However, render stages can safely call composition context

functions outside the <codeph>Begin()</codeph> and <codeph>End()</codeph> calls.

In addition, the <xref href="GUID-B1E048A2-D5E8-3E7F-A6AC-6B8F3ED3067C.dita"><apiname>MWsScreenDevice</apiname></xref> functions may be called

at any time. </p> </section>

<section id="GUID-B189C7EB-AD1F-51C6-91F1-8EBD49D8F69D"><title>MWsGraphicsContext</title> <p> <xref href="GUID-44844998-D8BF-3F2F-9BA2-FB9BB497F8C0.dita"><apiname>MWsGraphicsContext</apiname></xref> is

the interface for GDI-like drawing. The Window Server requests this interface

from the first render stage in the chain using the object provider mechanism.

This is a mandatory interface, which means that a render stage must not return

null when it receives an object provider request for this interface. However,

providing an implementation is not mandatory. For example, a logging render

stage might simply delegate to the next render stage instead of returning

its own implementation of this interface. </p> <p>The member functions correspond

to functions in <xref href="GUID-4A501086-7EFF-376D-8901-6D9B2EB4EFF2.dita"><apiname>CFbsBitGc</apiname></xref> (such as <codeph>DrawText()</codeph> and <codeph>BitBlt()</codeph>)

but without functions that are not suitable for hardware acceleration (such

as read-modify-write functions like <codeph>SetFaded()</codeph>). </p> <p>The

final render stage in the chain typically provides an implementation of <xref href="GUID-44844998-D8BF-3F2F-9BA2-FB9BB497F8C0.dita"><apiname>MWsGraphicsContext</apiname></xref> in

terms of a concrete rendering context—for example, by translating into BitGDI

or OpenVG calls. </p> <p>If <b>extended bitmaps</b> are supported on the device,

the implementation of the functions that receive a <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita"><apiname>CFbsBitmap</apiname></xref> as

an argument can check whether it is the handle to an extended bitmap. If it

is, the render stage can process the proprietary data within the bitmap. You

can get access to the proprietary data by using <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita#GUID-683A1D42-2764-3EB7-BD19-9E12559199AB/GUID-2AB943ED-7DBE-3FDA-82AF-317F152EDB03"><apiname>CFbsBitmap::DataAddress()</apiname></xref>.

Here is a simple example: </p> <codeblock id="GUID-390E236B-7EB1-5A90-B1F5-A0190403FF27" xml:space="preserve">// bmp points to a bitmap to be drawn.

TUid type = bmp->ExtendedBitmapType();

if (type==KUidMyProprietaryFormat)

    {    

    bmp->BeginDataAccess();

    const TUint32* data = bmp->DataAddress();

    TInt dataSize = bmp->DataSize();

    ProcessMyData(data, dataSize);

    bmp->EndDataAccess(ETrue);

    }

</codeblock> <p>For some data formats, particularly those that contain vector

data, such as SVG, this approach has advantages compared to letting the extended

bitmap rasterizer DLL process the proprietary data. For example, the extended

bitmap rasterizer DLL rasterizes the proprietary data into a pixel buffer,

which is then blitted to the screen. In contrast the render stage can insert

the drawing commands directly into the drawing command stream without the

use of intermediate pixel buffers. In addition, unlike the extended bitmap

rasterizer DLL, the render stage does not need to rasterize the image to a

higher resolution in order to scale it down. The use of the render stage to

process the proprietary data can therefore potentially save memory and improve

performance, depending on the data format. </p> <p>Although the Symbian Foundation

does not currently provide extended bitmap functionality in the main render

stages, it does provide a test extended bitmap render stage. You can use this

as an example when you implement your own extended bitmap functionality. </p> <p>For

more information, see <xref href="GUID-D76C7759-739D-5C98-B718-7297687FE630.dita">Extended

Bitmaps</xref>. </p> </section>

<section><title>MWsScene </title> <p> <xref href="GUID-43972649-4BDE-3D93-8658-35F224915A43.dita"><apiname>MWsScene</apiname></xref> is the composition

context interface for use with <xref href="GUID-8FE41C9A-8171-58A2-A808-17B81E79B11F.dita">OpenWF

composition</xref>. It is a mandatory interface. However, like <xref href="GUID-44844998-D8BF-3F2F-9BA2-FB9BB497F8C0.dita"><apiname>MWsGraphicsContext</apiname></xref>,

some render stages might simply delegate to the next render stage rather than

providing their own implementations. The final render stage in the chain typically

provides an implementation of <xref href="GUID-43972649-4BDE-3D93-8658-35F224915A43.dita"><apiname>MWsScene</apiname></xref> in terms of OpenWF-C. </p> <p>The <xref href="GUID-43972649-4BDE-3D93-8658-35F224915A43.dita"><apiname>MWsScene</apiname></xref> interface

defines the composition context for a particular screen (or an off-screen

buffer representing the screen) in terms of a collection of rectangular regions.

These are called <xref href="GUID-41802B91-26B3-5F3C-AE04-B6954F3804B7.dita">scene

elements</xref> or simply <b>elements</b>. Each one is represented by the <xref href="GUID-48B10795-1C8F-3D21-9637-6C7A02C95C75.dita"><apiname>MWsElement</apiname></xref> interface.

The <xref href="GUID-43972649-4BDE-3D93-8658-35F224915A43.dita"><apiname>MWsScene</apiname></xref> interface manages the relative ordinal positions

of the elements and uses the elements to track external surfaces and their

place in the composition scene. Render stages can manipulate element metadata

in order to perform transition effects and use the hardware-accelerated composition

facilities provided by OpenWF-C to perform transition effects (such as slide,

zoom and fade). </p> <p>Some of the key functions are: </p> <ul>

<li id="GUID-8265EB9F-14A5-54C5-B3EB-3925964121A5"><p> <codeph>CreateSceneElementL()</codeph>.

Creates a new element for use in the scene. After creation, an element is

available to the caller but <codeph>InsertSceneElement()</codeph> must be

called to actually insert it into the pending scene. </p> </li>

<li id="GUID-8736EC49-0C43-58AB-B9F1-397D2B7D6486"><p> <codeph>InsertSceneElement()</codeph>.

Inserts an element into the scene. </p> </li>

<li id="GUID-9016ACE1-E1BC-5126-A7D8-8A564CF96865"><p> <codeph>RemoveSceneElement()</codeph>.

Removes an element from the scene. </p> </li>

<li id="GUID-832568D5-4DCD-59CF-9982-2C6584AFC2B9"><p> <codeph>DestroySceneElement()</codeph>.

Destroys an element and removes its resources from the scene. </p> </li>

<li id="GUID-BA1D1346-EE28-5179-BBC9-300618162607"><p> <codeph>ComposePendingScene()</codeph>.

Renders the pending scene to an off-screen target. </p> </li>

<li id="GUID-AF8EFE14-B829-5B4B-998E-3CF161F027C1"><p> <codeph> RegisterSurface()</codeph>.

Marks a surface as potentially in use beyond its lifetime within the scene.

There are two typical use cases—one is where the contents of the surface (for

example, a video frame) must be maintained when users switch to another application

that hides the surface so that it is no longer part of the scene. This means

that users can have a seamless experience when they switch back to the video.

The other use case is where the content of a surface needs to be populated

before it is attached to a window and therefore added to the scene. </p> </li>

<li id="GUID-CE8BB038-0B65-5C78-B457-F7B532471826"><p> <codeph>UnregisterSurface()</codeph>.

Marks the surface as no longer in use beyond its inclusion in the scene. </p> </li>

</ul> <p>Any updates to the scene introduced by the render stage (such as

adding a new element) are pending until the Window Server calls <xref href="GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A.dita#GUID-B89CEF40-0139-3E6F-803D-F74E2BCB029A/GUID-0EBA06BF-D17F-3485-85B6-F4B855A48B62"><apiname>CWsRenderStage::End()</apiname></xref> to

commit the scene. </p> </section>

<section><title>MWsElement</title> <p> <xref href="GUID-48B10795-1C8F-3D21-9637-6C7A02C95C75.dita"><apiname>MWsElement</apiname></xref> is a

mandatory interface for managing scene elements when <xref href="GUID-8FE41C9A-8171-58A2-A808-17B81E79B11F.dita">OpenWF

composition</xref> is in use. This interface is obtained by using <xref href="GUID-43972649-4BDE-3D93-8658-35F224915A43.dita#GUID-43972649-4BDE-3D93-8658-35F224915A43/GUID-B776F464-8AAE-32C4-A0FF-026D8E553B7D"><apiname>MWsScene::CreateSceneElementL()</apiname></xref> rather

than the object provider mechanism. </p> <p>The <xref href="GUID-48B10795-1C8F-3D21-9637-6C7A02C95C75.dita"><apiname>MWsElement</apiname></xref> interface

provides a way of associating metadata with an image source. From the render

stage's point of view, the image source is a surface that is connected to

the element—whereas OpenWF-C has the concept of image sources that are created

from native streams. Because the <xref href="GUID-83510B5B-9725-5272-BF51-23A089178DAC.dita">OpenWF-C

Support component</xref> implements native streams in terms of Symbian surfaces,

the render stage can ignore this distinction and simply cast the address of

the <xref href="GUID-11F60AEB-003B-3E8D-BDB9-D97F698627DF.dita"><apiname>TSurfaceId</apiname></xref> to the OpenWF-C native stream type (<xref href="GUID-DF6DF530-EC4E-32D4-9CC8-536F3F2BE83E.dita"><apiname>WFCNativeStreamType</apiname></xref>). </p> <p>The

element metadata includes the following: </p> <ul>

<li id="GUID-BD2BD787-B90D-5E00-A533-7401CB4A7CB4"><p>Source rectangle—the

region within the surface from which pixels are taken. This enables the surface

to be cropped and is equivalent to the surface viewport described in <xref href="GUID-495EA1C8-E95F-54AE-B4D1-0F463003C2D7.dita">External Surfaces Overview</xref>. </p> </li>

<li id="GUID-CFD9C7F9-78EA-5719-A5F1-DD2D78ECFEE8"><p>Destination rectangle—the

target rectangle in the composition output to which the pixels are rendered.

This is equivalent to the extent. </p> </li>

<li id="GUID-9EE4ECD3-7274-553B-8123-250EE3E7751A"><p>Global alpha—a global

alpha value for use in blending the surface into the composition output. </p> </li>

<li id="GUID-1FA2DF2A-2FBC-551B-B4D9-6D6711F46D39"><p>Source rotation—the

number of quadrant angles by which the contents of the surface are rotated. </p> </li>

<li id="GUID-3830D1D3-8687-5C7A-B886-F1B0CED6BF26"><p>Source flipping—a Boolean

value that indicates whether the contents of the surface are flipped. </p> </li>

<li id="GUID-7535C9D7-314C-5EF6-8D50-226DC5F2DE33"><p>Target renderer flags—these

provide information to the rendering subsystem (for example, the OpenWF-C

engine), such as whether the renderer should blend based on the global alpha

value or the alpha channel in the surface itself. </p> </li>

<li id="GUID-8B50BD6E-5F9A-5690-99CC-73AE8D129B52"><p>Render stage flags—these

provide information to the render stages, such as whether the UI surface is

always on top. </p> </li>

</ul> </section>

<section><title>MWsScreenDevice</title> <p> <xref href="GUID-B1E048A2-D5E8-3E7F-A6AC-6B8F3ED3067C.dita"><apiname>MWsScreenDevice</apiname></xref> is

the interface for managing the screen. It provides functions for controlling

rotation and fetching data from the screen such as a screen snapshot. </p> </section>

<section><title>MWsTextCursor</title> <p> <xref href="GUID-F43CBB9C-238B-33C5-B872-AAE0104F047E.dita"><apiname>MWsTextCursor</apiname></xref> is

an interface that enables render stages to implement a text cursor to represent

the flashing bar or rectangle that represents the current position when editing

text. </p> <p>Prior to the introduction of ScreenPlay text cursors were drawn

using XOR drawing because it provides high contrast against the background.

Render stages can implement this interface using the same approach but it

is generally inefficient on hardware-accelerated platforms. Therefore another

approach, such as a drop shadow or sprite, might be preferable. </p> <p>The

preferred solution is that clients use <xref href="GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9.dita#GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9/GUID-684910B9-CCEA-3798-BE23-967820BBF363"><apiname>RWsSession::SetCustomTextCursor()</apiname></xref> to

replace the text cursor with a sprite. This means that user themes can use

a sprite that matches the text—for example, a white sprite with white text

and a black sprite with black text. If a client does this, the render stage’s <xref href="GUID-F43CBB9C-238B-33C5-B872-AAE0104F047E.dita"><apiname>MWsTextCursor</apiname></xref> API

is not used when drawing text cursors for that client. Instead, the text cursor

sprite is drawn using GDI draw operations through the <xref href="GUID-44844998-D8BF-3F2F-9BA2-FB9BB497F8C0.dita"><apiname>MWsGraphicsContext</apiname></xref> interface. </p> </section>

<section><title>MWsFader</title> <p> <xref href="GUID-1CF41CFD-27C8-39D7-A615-18CE765436DE.dita"><apiname>MWsFader</apiname></xref> is the interface

for providing fading capabilities. </p> </section>

<section><title>MWsWindowTreeObserver</title> <p> <xref href="GUID-028CC583-AC32-3D60-943A-A80F84E05DD2.dita"><apiname>MWsWindowTreeObserver</apiname></xref> is

an optional interface that enables a render stage to create a replica of the

window tree, known as the <b>visuals tree</b>. The Window Server uses this

interface to tell the render stage about the window tree structure and changes

to window tree nodes. Note that this interface considers animations and sprites

to be nodes in the window tree. </p> <p>See the <xref href="GUID-2E8929E6-9555-51D2-B41D-6F1D05A4DB87.dita#GUID-2E8929E6-9555-51D2-B41D-6F1D05A4DB87/GUID-5D81D1A7-26A0-5461-9AC5-3EF359D283CB">Advanced

Use Case</xref> section of the <xref href="GUID-2E8929E6-9555-51D2-B41D-6F1D05A4DB87.dita">Render

Stages Overview</xref> for more information. </p> </section>

<section id="GUID-7536F610-F9F7-5E17-82D8-623D774DC091"><title>MWsDrawAnnotationObserver</title> <p> <xref href="GUID-21240143-D578-3114-9836-F765F70A987C.dita"><apiname>MWsDrawAnnotationObserver</apiname></xref> is

an optional interface that enables render stages to associate a batch of drawing

operations with a specific window or node in the visuals tree. TFX render

stages generally need to implement this interface. </p> <p>If the render stage

implements the <xref href="GUID-028CC583-AC32-3D60-943A-A80F84E05DD2.dita"><apiname>MWsWindowTreeObserver</apiname></xref> interface, implementing

the <codeph>MWsDrawAnnotationObserver</codeph> interface enables the render

stage to know which node in the visuals tree each batch of drawing operations

belongs to. This means that the render stage can associate the batch with

the correct window, sprite or other element in the visuals tree and manage

it efficiently. </p> <p>If the render stage does <b>not</b> implement the <codeph>MWsWindowTreeObserver</codeph> interface,

the <codeph>MWsDrawAnnotationObserver</codeph> interface still provides the

window tree node pointers for each batch of drawing operations. There are

two different approaches this type of render stage can take: </p> <ul>

<li id="GUID-3248DECC-4F1E-5504-AC00-751D33D032A5"><p>The render stage can

treat the window tree node pointers as unique identifiers for the windows.

This approach is typically used when the Window Server's default <xref href="GUID-22093E74-EFE7-5642-93DE-1573E18F7C08.dita">dirty-rectangle

rendering mode</xref> is in use. In this mode the Window Server sends the

batches of drawing operations to the first render stage in back to front z-order.

(That is, the drawing operations for the windows in the background come before

the drawing operations for the windows at the front.) Using the unique identifier

and the z-order, the render stage can identify new windows that are at the

top and slide them on or perform some other transition effect. </p> <p>This

approach is suitable when the render stage always performs the same transition

effect. For example, the render stage slides on all new windows that are at

the front. </p> </li>

<li id="GUID-F21BC536-DE1C-585C-B183-AF499AC31FC6"><p>The other approach is

suitable when the render stage applies transition effects to specific windows;

for example, windows that belong to a media player application. In this scenario,

the client communicates the handles of those windows to the render stage.

The render stage uses the <codeph>MWsDrawAnnotationObserver</codeph> to retrieve

the handles of the windows to which the drawing operations relate. The render

stage compares these handles with those communicated by the client and for

which the transition effects are required. When a handle matches, the render

stage performs the transition effect. When the handle does not match, the

render stage passes the drawing operations straight through to the next render

stage in the chain. </p> <p>The following code snippet shows how to retrieve

a window's handle from the <xref href="GUID-7837D4F3-4BF4-344B-B987-6789060553B3.dita"><apiname>MWsWindowTreeNode</apiname></xref> object returned

by the <codeph>MWsDrawAnnotationObserver</codeph> functions: </p> <codeblock id="GUID-156D0D65-0746-5FED-BB8F-8188D6B2C7F7" xml:space="preserve">windowID = aWindowTreeNode.Window-&gt;Handle();</codeblock> <p> <i>Note</i>:

Communication of the window handle from the client to the render stage is

beyond the scope of this documentation. </p> </li>

</ul> </section>

<section><title>MWsWindowVisibilityNotifier</title> <p> <xref href="GUID-FF3EE463-E775-3948-B1EB-66135E24A623.dita"><apiname>MWsWindowVisibilityNotifier</apiname></xref> is

an optional interface that enables a render stage to communicate changes in

the visibility of windows and other nodes in the window tree to the Window

Server. A render stage that works in <xref href="GUID-22093E74-EFE7-5642-93DE-1573E18F7C08.dita">change-tracking

rendering mode</xref> must implement this interface. </p> <p>When the Window

Server is in its default dirty-rectangle tracking mode, it tracks which windows

are visible and sends visibility-changed events to clients, Content Rendering

Plug-ins (CRPs) and animation plug-ins. This enables these clients to know

when their windows are visible and therefore need to draw or animate, and

when they are obscured and do not need to draw or animate. This means that

CPU cycles are not wasted producing animations when they are not visible and

ensures that animations run when they are visible. </p> <p>When the Window

Server is in change-tracking mode, it does not track the visible regions and

tracking of visible regions is delegated to the render stage. At the minimum,

the render stage must set the visible region to be the whole window or none

of it. </p> <p>The Window Server implements the <xref href="GUID-9CF4DEE1-57D8-3F57-93B2-6EB701262AD7.dita"><apiname>MWsWindowVisibilityObserver</apiname></xref> interface

through which it responds to visibility change notifications sent by the render

stage. </p> </section>

<section><title>MWsDisplayControl</title> <p> <xref href="GUID-415B5416-A6DD-3471-8800-C76C48DA59DA.dita"><apiname>MWsDisplayControl</apiname></xref> is

the interface for controlling the display configuration. See <xref href="GUID-2B6D3A9D-1481-5587-A954-48CE7EC311EE.dita">Render

Stage Display Control and Mapping</xref> for more information. </p> </section>

<section><title>MWsDisplayMapping</title> <p> <xref href="GUID-ED4CAB66-F8F8-3AF2-A388-F28406A3B104.dita"><apiname>MWsDisplayMapping</apiname></xref> is

the interface for mapping between coordinate spaces. See <xref href="GUID-2B6D3A9D-1481-5587-A954-48CE7EC311EE.dita">Render

Stage Display Control and Mapping</xref> for more information. </p> </section>

<section><title>MWsDisplayPolicy</title> <p> <xref href="GUID-0A31CF3E-25A9-36BA-80D6-8FBD18419506.dita"><apiname>MWsDisplayPolicy</apiname></xref> is

an optional interface, which if implemented, determines the UI to composition

mapping policy. See <xref href="GUID-2B6D3A9D-1481-5587-A954-48CE7EC311EE.dita">Render

Stage Display Control and Mapping</xref> for more information. </p> </section>

</conbody><related-links>

<link href="GUID-2E8929E6-9555-51D2-B41D-6F1D05A4DB87.dita"><linktext>Render Stage

Overview</linktext></link>

<link href="GUID-309B01B6-F74A-5EF0-B225-702BF8814847.dita"><linktext>TFX Render

Stage                 Examples</linktext></link>

<link href="GUID-2B6D3A9D-1481-5587-A954-48CE7EC311EE.dita"><linktext>Display 

               Control and Mapping</linktext></link>

<link href="GUID-98EA7E2B-4AC6-55AE-985F-B5EE1E0A79E7.dita"><linktext>Creating

a Render Stage                 Plug-in</linktext></link>

<link href="GUID-41802B91-26B3-5F3C-AE04-B6954F3804B7.dita"><linktext>Scene Elements</linktext>

</link>

<link href="GUID-D76C7759-739D-5C98-B718-7297687FE630.dita"><linktext>Extended

Bitmaps</linktext></link>