Chapter 1

� introducing bitmap handling
� more on font management
� more on printing
� color and display modes
� web browsing.
15.2.1 Blitting and Bitmaps
These days, displays are fundamentally bitmap-oriented. Graphics primitives such as
DrawLine() have to rasterize or render the line – that is, they must determine which
pixels should be drawn in order to create a bitmap image that looks like the desired line.
Rasterizing in the Symbian OS is the responsibility of the BITGDI, which implements all
drawing functions specified by CGraphicsContext for drawing to onand offscreen
bitmaps.
Another approach to updating a bitmapped display is simply to blit to it: to copy a bitmap
whose format is compatible with the format on the display. Blitting is extremely efficient if the
source and destination bitmaps are of identical format.
Any GUI worth its salt takes advantage of the efficiency of blitting to optimize certain
operations:
� On-screen icons are not rendered using drawing primitives, but pre- constructed in a
paint program and blitted to screen when required.
� Flicker-free screen redraws are performed by rendering to an offscreen bitmap
(potentially slow), and then blitting to the screen when needed (usually quick). The
offscreen bitmap is maintained by RBackedUp-Window, a class of the window server.
This provides an aid to getting flicker-free fast redraws as whenever a redraw is
required and the window contents haven't changed. The image can simply be blitted
from the screen and not redrawn from scratch. Redrawing is done entirely from the
backup bitmap.
� Animation is a special case of flicker-free update that can be implemented using a
sequence of blits, one for each image frame.
� Screen fonts are blitted from the font bitmaps onto the screen (or offscreen bitmap).
Blitting is great, but it isn't always the best thing to use.
� Bitmaps use a lot of memory, so if you can construct a picture from a short sequence
of drawing primitives, it's often more compact than storing the picture as a bitmap.
� Bitmaps can't be scaled effectively: you lose information if you scale them down and
they look chunky if you scale them up. Also, scaling is generally slow, which eliminates
one of the major advantages of using bitmaps.
� Bitmaps are fixed. You can only use them to store predrawn or precalculated pictures,
or to cache calculated images for reuse over a short period of time.
� Bitmaps are highly efficient for screens, but highly inefficient for printers, because they
involve large data transfers over relatively slow links. They also involve scaling, but
usually that's acceptable on printers because the scaling is to a size similar to that
which would have been used for the bitmap on screen anyway.
Here's a UML diagram of bitmap support classes in Symbian OS: