<?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-08A6A034-5609-58B0-8EA7-943B2A937B40" xml:lang="en"><title>Displayable

Windows</title><shortdesc>The<codeph>RWindowBase</codeph> class is the abstract

base class for all windows that can be displayed. These windows further subdivide

into two types: windows that can be drawn to (<codeph>RDrawableWindow</codeph> abstract

class), and blank windows (<codeph>RBlankWindow</codeph> class).</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>

<p> <b>Variant</b>: Both (ScreenPlay and non-ScreenPlay). <b>Target audience</b>:

Application developers. </p>

<p>Displayable windows introduce several attributes and associated functions: </p>

<ul>

<li id="GUID-9432F9B6-29F1-547C-A6B0-8A380C4F3E36"><p>All windows have a rectangle

that defines the area in which they are contained. Most windows fill all of

this area, but you can set rounded corners or specify any arbitrary region

for the window's area. </p> </li>

<li id="GUID-81D8BEA8-5CD8-56A5-8A9C-5B18BA0B44E4"><p>Whether the window is

visible or not, controlled by the <xref href="GUID-1460DD8F-9AA1-3B99-8FFD-F309959CCA34.dita#GUID-1460DD8F-9AA1-3B99-8FFD-F309959CCA34/GUID-A028954C-B8A7-3954-B0F7-47E79ACF5DD7"><apiname>RWindowBase::SetVisible()</apiname></xref> function. </p> </li>

<li id="GUID-840930B6-6955-5A43-9A23-8678EA7ADABC"><p>For pointer event control,

see <xref href="GUID-CD550DE7-D013-527B-BADE-5CB122C352C8.dita">Pointer Handling</xref>. </p> </li>

</ul>

<p>The Window Server maintains the screen display taking into account the

region, ordinal position and visibility requirements of all displayable windows. </p>

<section id="GUID-626A91B0-451B-4034-B3F4-DE024140E76D"><title>Standard windows</title> <p>The <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref> class

is derived from <codeph>RDrawableWindow</codeph>. These windows require very

little RAM and are therefore the most common type of window used by Symbian

applications. </p> <p>Provided drawing operations to an <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref> are

performed as <xref href="GUID-8DB1C618-597C-560C-95A2-C0AB2CEBB027.dita">redraw

drawing</xref>, the Window Server stores the sequence of drawing commands

that represent the window contents in redraw stores. Then when the Window

Server needs to repaint the window (because, for example, a dialog box popped

up over it and has now closed) it simply replays the sequence of stored commands,

rather than sending a redraw request to the client. This minimises the number

of client-server transactions and means that windows are repainted as soon

as the Window Server detects that they are needed. </p> </section>

<section id="GUID-1FCF8A1B-36A9-404E-8950-B5E88EC04100"><title>Backed-up windows</title> <p>This feature is deprecated in

Symbian^3. </p> <p>A backed-up window is provided by the <xref href="GUID-27A95595-F74D-32B2-A960-0CA290C8A3B3.dita"><apiname>RBackedUpWindow</apiname></xref> class.

The Window Server stores the window contents in a bitmap rather than as a

sequence of draw operations in redraw stores. When the window needs to be

redrawn, the Window Server blits the bitmap to the window. This usually consumes

much more memory than storing the drawing operations in the redraw store.

For example, to store the drawing operations for a simple window would typically

require fewer than 100 bytes. Storing the bitmap for the equivalent window

would typically require hundreds of kilobytes. </p> <p>There are two different

approaches to working with backed-up windows: </p> <ul>

<li id="GUID-45934BD6-928C-5780-AB79-4F53612865D7"><p>The direct bitmap access

functions allow the application to directly access the bitmap used by the

Window Server for backing up the window. By default, areas of a backed-up

window that are currently visible on the screen are not backed up. When a

region of the window is covered by another window, that region's contents

are copied to the bitmap before being covered over on the screen. </p> </li>

<li id="GUID-CA85FC82-8009-5D33-B3B4-669ADBDD8F7F"><p>An alternative approach

is provided by the <xref href="GUID-27A95595-F74D-32B2-A960-0CA290C8A3B3.dita#GUID-27A95595-F74D-32B2-A960-0CA290C8A3B3/GUID-28A5B6DD-3471-3F74-8D7B-808750018968"><apiname>RBackedUpWindow::MaintainBackup()</apiname></xref> function.

This causes the backup bitmap to contain a copy of the entire window contents

at all times. However, it may produce a reduction in performance, because

the Window Server must subsequently carry out all drawing commands on both

the screen and the bitmap. The more drawing-intensive an application, the

more severe this degradation in performance is. </p> </li>

</ul> </section>

</conbody><related-links>

<link href="GUID-99AE1D62-571A-5A63-B472-C0FBC0861F52.dita"><linktext>Window Types</linktext>

</link>

</related-links></concept>