|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-08A6A034-5609-58B0-8EA7-943B2A937B40" xml:lang="en"><title>Displayable |
|
13 Windows</title><shortdesc>The<codeph>RWindowBase</codeph> class is the abstract |
|
14 base class for all windows that can be displayed. These windows further subdivide |
|
15 into two types: windows that can be drawn to (<codeph>RDrawableWindow</codeph> abstract |
|
16 class), and blank windows (<codeph>RBlankWindow</codeph> class).</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
17 <p> <b>Variant</b>: Both (ScreenPlay and non-ScreenPlay). <b>Target audience</b>: |
|
18 Application developers. </p> |
|
19 <p>Displayable windows introduce several attributes and associated functions: </p> |
|
20 <ul> |
|
21 <li id="GUID-9432F9B6-29F1-547C-A6B0-8A380C4F3E36"><p>All windows have a rectangle |
|
22 that defines the area in which they are contained. Most windows fill all of |
|
23 this area, but you can set rounded corners or specify any arbitrary region |
|
24 for the window's area. </p> </li> |
|
25 <li id="GUID-81D8BEA8-5CD8-56A5-8A9C-5B18BA0B44E4"><p>Whether the window is |
|
26 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> |
|
27 <li id="GUID-840930B6-6955-5A43-9A23-8678EA7ADABC"><p>For pointer event control, |
|
28 see <xref href="GUID-CD550DE7-D013-527B-BADE-5CB122C352C8.dita">Pointer Handling</xref>. </p> </li> |
|
29 </ul> |
|
30 <p>The Window Server maintains the screen display taking into account the |
|
31 region, ordinal position and visibility requirements of all displayable windows. </p> |
|
32 <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 |
|
33 is derived from <codeph>RDrawableWindow</codeph>. These windows require very |
|
34 little RAM and are therefore the most common type of window used by Symbian |
|
35 applications. </p> <p>Provided drawing operations to an <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita"><apiname>RWindow</apiname></xref> are |
|
36 performed as <xref href="GUID-8DB1C618-597C-560C-95A2-C0AB2CEBB027.dita">redraw |
|
37 drawing</xref>, the Window Server stores the sequence of drawing commands |
|
38 that represent the window contents in redraw stores. Then when the Window |
|
39 Server needs to repaint the window (because, for example, a dialog box popped |
|
40 up over it and has now closed) it simply replays the sequence of stored commands, |
|
41 rather than sending a redraw request to the client. This minimises the number |
|
42 of client-server transactions and means that windows are repainted as soon |
|
43 as the Window Server detects that they are needed. </p> </section> |
|
44 <section id="GUID-1FCF8A1B-36A9-404E-8950-B5E88EC04100"><title>Backed-up windows</title> <p>This feature is deprecated in |
|
45 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. |
|
46 The Window Server stores the window contents in a bitmap rather than as a |
|
47 sequence of draw operations in redraw stores. When the window needs to be |
|
48 redrawn, the Window Server blits the bitmap to the window. This usually consumes |
|
49 much more memory than storing the drawing operations in the redraw store. |
|
50 For example, to store the drawing operations for a simple window would typically |
|
51 require fewer than 100 bytes. Storing the bitmap for the equivalent window |
|
52 would typically require hundreds of kilobytes. </p> <p>There are two different |
|
53 approaches to working with backed-up windows: </p> <ul> |
|
54 <li id="GUID-45934BD6-928C-5780-AB79-4F53612865D7"><p>The direct bitmap access |
|
55 functions allow the application to directly access the bitmap used by the |
|
56 Window Server for backing up the window. By default, areas of a backed-up |
|
57 window that are currently visible on the screen are not backed up. When a |
|
58 region of the window is covered by another window, that region's contents |
|
59 are copied to the bitmap before being covered over on the screen. </p> </li> |
|
60 <li id="GUID-CA85FC82-8009-5D33-B3B4-669ADBDD8F7F"><p>An alternative approach |
|
61 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. |
|
62 This causes the backup bitmap to contain a copy of the entire window contents |
|
63 at all times. However, it may produce a reduction in performance, because |
|
64 the Window Server must subsequently carry out all drawing commands on both |
|
65 the screen and the bitmap. The more drawing-intensive an application, the |
|
66 more severe this degradation in performance is. </p> </li> |
|
67 </ul> </section> |
|
68 </conbody><related-links> |
|
69 <link href="GUID-99AE1D62-571A-5A63-B472-C0FBC0861F52.dita"><linktext>Window Types</linktext> |
|
70 </link> |
|
71 </related-links></concept> |