TheRWindowBase 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 (RDrawableWindow abstract class), and blank windows (RBlankWindow class).
Variant: Both (ScreenPlay and non-ScreenPlay). Target audience: Application developers.
Displayable windows introduce several attributes and associated functions:
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.
Whether the window is visible or not, controlled by the RWindowBase::SetVisible() function.
For pointer event control, see Pointer Handling.
The Window Server maintains the screen display taking into account the region, ordinal position and visibility requirements of all displayable 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.
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.