Overview of Series 60 Graphics Architecture

Graphics programming in Series 60 focuses primarily on interactions with the three servers: the Window Server , the Font and Bitmap Server and the Multi Media Server . Each plays a vital role in providing an all-encompassing set of APIs for performing virtually any kind of graphics operation.

The Window Server gives client applications access to the essential input and output resources of the device keypad and screen, respectively. The Font and Bitmap Server, as its name suggests, manages fonts and bitmaps in memory, so that they can be used in the most efficient manner possible. Finally, the Multi Media Server is employed for image conversion and manipulation.

While communication with these various components does involve a Client/Server relationship, many of the provided classes abstract away the complexities of this, and the Client/Server interactions are effectively hidden.

Window Server

The Window Server enables applications to interact with a device's screen and its input mechanisms, such as the keypad. Consequently, any application with a user interface will need to use the Window Server. Client applications will invoke asynchronous requests , via an interface to the Window Server, which decides on the application that should have access to the device screen, and receive user input.

This interface is a "session" with the Window Server and is represented by the RWsSession class. Figure 11-1 shows how the Window Server controls device hardware through these sessions.

Figure 11-1. The flow of control for applications through sessions with the Window Server.

The aspects of RWsSession that concern you are: windows , events, and the client-side buffer.

• Windows represent an area on the screen that can be drawn to. Applications will redraw using the RWindow class, which represents a handle to a standard window, derived from the abstract base class RDrawableWindow . The various types of window are extensively illustrated in the SDK documentation.

• There are three types of Window Server event that applications can be made aware of: a priority key press, such as the power button, triggers a TWsPriorityKeyEvent ; a standard key press triggers a TWsEvent ; and a TWsRedrawEvent occurs when a redraw is necessary.

• The Client/Server nature of the Window Server means that, in order for it to carry out drawing operations, a context switch is necessary from your application. There can be severe overhead in this, so a buffer of drawing events is maintained client-side ”in other words, in the application. This is dispatched to the Window Server in one go, thereby minimizing the number of context switches. Flushing of this buffer takes place for a variety of reasons, but generally it will happen when the buffer is full or you have explicitly called RWsSession::Flush() .

The presence of the client-side buffer means that when debugging, stepping through a drawing command will not result in the emulator display being updated. To overcome this, the debugging hotkey sequence Ctrl+Alt+Shift+F can be used to enable autoflushing of the client-side buffer. It should be noted that this will be detrimental to performance if permanently enabled, however it is a useful debugging aid. A full list of emulator keyboard shortcuts is available in Appendix A.

In truth, discussing RWsSession is analyzing matters at a very "low level," and any application that employs the Series 60 application framework will have access to a variety of classes that hide such explicit Window Server interaction. These classes allow for relatively straightforward drawing to, and interrogation of, the screen, and they are conceptually similar to the mechanisms employed on other platforms. For example, classes derived from CGraphicsContext are analogous to the Graphics class in Java. Occasionally, however, you will be required to pass RWsSession objects around your code ”so that these classes can have access to the Window Server ”and so an appreciation of RWsSession is useful.

Font and Bitmap Server

The Font and Bitmap Server exists to allow fonts and bitmaps to be used in a manner that is both memory and speed efficient. As with the Window Server, applications are clients of the Font and Bitmap Server, and this allows fonts and bitmaps to be shared across the system, thereby reducing memory overhead.

Fonts and bitmaps are loaded into memory once, and a reference counter is used to determine how many clients require access to each resource. When the reference counter is zero, it indicates the resource is no longer needed and can be removed from memory. Parallels with the Window Server are again evident, with the RFbsSession class performing a function similar to that of RWsSession , in communications with the Font and Bitmap Server. However, in practice, an RFbsSession object is rarely seen, as the more readily usable classes of the Font and Bitmap Server, such as CFbsBitmap (which represents a bitmap), encapsulate it.

The Font and Bitmap Server plays another vital role in providing off-screen memory for bitmap manipulation, and in implementing double buffering, which is essential for flicker-free redrawing ”for example, while animating. By using the CFbsBitmapDevice , CFbsBitGc and CFbsBitmap classes together, you can perform off-screen graphics operations. This is demonstrated in the Bitmaps section of this chapter.

The Window Server and the Font and Bitmap Server

Viewing the Window Server and the Font and Bitmap Server might lead you to conclude that they exist as distinct entities. While it is true that their roles differ , ultimately it is the coming together of the two that allows you to perform serious graphics operations on a Series 60 device. If graphics are prepared off screen using the Font and Bitmap Server classes, the Window Server classes will be needed in order to actually draw them to the screen. Indeed, the construction of an RFbsSession takes place when an RWsSession is created. Consequently, all Window Server clients are also Font and Bitmap Server clients.

Although the Window Server provides access to the device screen, this is not the same as having direct access to the screen. This is achieved through specialized classes and is discussed, with an example, in the Direct Screen Access section of this chapter.

Multi Media Server

While the Window Server and Font and Bitmap Server are somewhat entwined, the Multi Media Server is more independent, playing a key role in the management of images by providing the tools for image conversion and manipulation. Using the specialist classes of the Multi Media Server, images can be converted to and from a variety of industry standard file formats. The image formats supported are shown in Table 11-1.

Table 11-1. Image Formats Supported by the Multi Media Server

Image Format
BMP (Bitmap)	TIFF (Tagged Image File Format)
GIF (Graphics Interchange Format)	WBMP (Wireless Bitmap)
MBM (Multi Bitmap)	ICO (Icon)
PNG (Portable Network Graphics)	WMF (Windows Meta File)
SMS OTA (Over the Air)

At the same time, classes are provided to perform rotation and scaling of images. Ultimately, images loaded and manipulated by the Multi Media Server will need to be stored in memory to be of practical use for display and interrogation purposes. This is achieved by using the bitmap classes provided, so once again there is a degree of crossover between the key graphics Servers.

The libraries to which the various components mentioned so far belong are listed in Table 11-2.

Table 11-2. Series 60 Graphics Libraries ^[*]

Library (.lib)	Role	Key Elements
GDI	Basic framework from which all graphics derive.	Fonts, geometry, color , graphics devices and contexts.
BITGDI	Basic framework from which all bitmapped graphics derive.	Bitmapped graphics devices and graphics contexts.
FBSCLI	Font and Bitmap Server client-side.	Bitmaps, fonts, Font and Bitmap Server sessions.
WS32	Window Server client-side.	Window types, Window Server sessions, Window Server bitmaps, Window Server graphics contexts and devices.
MEDIACLIENTIMAGE	Multi Media Server client-side.	Image conversion, rotation and scaling.

^[*] Audio libraries are covered in Table 11-13.