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.