Introduction to Font and Bitmap Server

The font and bitmap server manages fonts and bitmaps that may reside in ROM or on some other drive. Bitmaps are stored in a shared-memory heap and are directly accessible to all graphics programs, and the window server. ROM-based fonts and bitmaps are used directly from ROM. File-based fonts and bitmaps are loaded only once, and deleted from RAM when no longer needed by any client.

The server manages sharing of fonts and bitmaps between all client threads. It is conventional in that it is a single server to manage all these system resources on behalf of all clients. There are two main motivations for its presence:

• for fonts and bitmaps loaded from removable media into RAM, only a single instance of each font or bitmap is loaded into RAM: a reference count is maintained if multiple clients need to access it. The font or bitmap is removed from RAM if the reference count reduces to zero.

• a standard technique for smooth animation is for a client program to prepare an off-screen bitmap and then have the window server blit it to the screen. The server manages all bitmaps in a single shared memory area accessible to both the window server and its clients. The window server may therefore efficiently blit a bitmap prepared by one of its clients, without transferring the bitmap data itself between client and window server.

The server is used to manage all fonts and bitmaps, including those in ROM.

The server presents a conventional client API through RFbsSession, representing a session from client to server. The classes CFbsFont and CFbsBitmap (documented as parts of the Fonts API and Bitmaps API respectively) represent client-side font and bitmap classes.

The server is, however, slightly unusual in that the RFbsSession is stored in client-side thread-local storage. The constructors for CFbsFont and CFbsBitmap find this session handle automatically: the client program does not have to pass it as a parameter. Therefore, to most client programs, the client/server nature is hidden from the API.

The RFbsSession is created for clients by the window server’s client API when an window server session, RWsSession, is constructed. A window server client is therefore always an Font and Bitmap Server client.

RFbsSession has a callback. When a resource is released by a client, the API invokes the callback. In the (usual) case that the client is a window server client, the window server’s client API handles the callback by flushing its client-side buffer. The window server, as a high-priority thread, then performs any drawing operations that might need the font or bitmap. Only when this has completed does the server release the resource. Without this mechanism, it would be possible for the server to release a resource before it is required by the window server.