Displayable +Windows

Variant: Both (ScreenPlay and non-ScreenPlay). Target audience: +Application developers.

The Window Server maintains the screen display taking into account the +region, ordinal position and visibility requirements of all displayable windows.

Standard windows

The RWindow class +is derived from RDrawableWindow. These windows require very +little RAM and are therefore the most common type of window used by Symbian +applications.

Provided drawing operations to an RWindow are +performed as redraw +drawing, 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.

Backed-up windows

This feature is deprecated in +Symbian^3.

A backed-up window is provided by the RBackedUpWindow 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.

There are two different +approaches to working with backed-up windows:

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.
An alternative approach +is provided by the RBackedUpWindow::MaintainBackup() 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.