The Font and Bitmap Server Overview

Key terms

Bitmap

A two-dimensional (2D) buffer (in memory) that contains the color values for individual pixels and is encapsulated by the CFbsBitmap class.

Extended bitmap

A bitmap that contains data compressed using proprietary formats.

Raster image

A data structure representing a rectangular grid of pixels. Scaling raster images usually leads to a loss of quality.

Vector image

The use of geometrical primitives such as points, lines, curves and polygons to represent an image. Vector images can be scaled without loss of quality.

Rasterization

The process of converting vector image drawing instructions into a raster image that can be displayed on the screen.

Scan line

A row of pixels in a raster image. This use of the term is derived from its original use in a raster scanning pattern, such as a video line on the cathode ray tube (CRT) display of a television.

For font-related terms, see Font and Text Services Collection Overview .

Architectural relationships

The Font and Bitmap Server is tightly integrated with the BitGDI and Window Server components. It provides client-side classes for fonts, bitmaps and the typeface store.

In use the Font and Bitmap Server is largely transparent. When a client of the Window Server opens a Window Server session, that session silently creates an RFbsSession and stores it in Thread Local Storage (TLS). Client-side font and bitmap classes such as CFbsFont and CFbsBitmap automatically find the session in TLS when they are constructed. (These are client-side objects that refer to objects in the server. Because they are heap-based classes, they have names beginning with C.)

The Font and Bitmap Server contains the font store, which is a separate DLL provided by the Font Store (FntStore) component . Client-side access to the font store is through CFbsTypefaceStore .

Description

The Font and Bitmap Server is a singleton process that owns fonts and bitmaps. CFbsFont and CFbsBitmap objects are actually client-side handles to the font and bitmap objects, which are stored on a globally accessible heap while they are in use. Bitmap data is stored separately in a globally accessible disconnected chunk.

When the reference count of clients using a font or bitmap that is resident in RAM falls to zero, the server can delete it and free the memory. XIP ROM based bitmaps are accessed in place, not copied into RAM.

Open fonts, which are stored in font files as vector data, must be rasterized into the Font and Bitmap Server's shared heap. Rasterizers are plug-ins to the Font Store component. There is a performance overhead to rasterizing an open font and a memory overhead for storing it.

API summary

The Font and Bitmap Server presents a conventional client API through RFbsSession , which represents the handle to a server-side session. The classes CFbsFont and CFbsBitmap are client-side representations of font and bitmap classes.

• The CFbsFont class represents fonts managed by the Font and Bitmap Server, both bitmap fonts and OpenType fonts.

• The CFbsBitmap class represents bitmaps managed by the Font and Bitmap Server, both RAM and XIP ROM-based bitmaps. For RAM-based bitmaps, this class provides facilities for creating, loading, saving, and resizing bitmaps. RAM-based bitmaps are commonly loaded from a multi-bitmap file (. mbm ) file or created as off-screen bitmaps, and then blitted to a window. For XIP ROM-based bitmaps, CFbsBitmap provides facilities for accessing the data.

The Font and Bitmap Server is unusual in that the RFbsSession is stored in client-side thread local storage (TLS). 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 of using fonts and bitmaps is hidden from the API.

The RFbsSession is created for clients by the Window Server’s client-side API when a Window Server session, RWsSession , is constructed. A Window Server client is therefore also a client of the Font and Bitmap Server.

When a client calls, for example, the CWindowGc::DrawBitmap() function, the handle number of the bitmap is passed to the Window Server through inter-process communication (IPC). Like all CWindowGc drawing commands, the handle number is stored in a client-side command buffer, which by default is flushed to the server side only when it is full. Once flushed to the server-side, the command buffer is processed by the Window Server rendering loop . Consider the scenario where an application calls CWindowGc::DrawBitmap() and then closes the bitmap before the client-side buffer is flushed. There needs to be some mechanism to prevent the bitmap’s reference count from reaching zero and hence being deleted before the Window Server can render it. For this reason, RFbsSession has a callback, which is invoked whenever a client closes a bitmap handle. The callback causes an immediate flush of the Window Server client-side command buffer. The Window Server then creates on the server side a duplicate CFbsBitmap for the bitmap. This increases the bitmap's reference count and therefore prevents it from being deleted before the Window Server attempts to render it. The same mechanism applies to font handles. This mechanism is transparent to clients of the Window Server.