<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept xml:lang="en" id="GUID-71DADA82-3ABC-52D2-8360-33FAEB2E5DE9"><title>The Font and Bitmap Server Overview</title><shortdesc>The Font and Bitmap Server (FBServ) provides a memory efficient way of using bitmaps and fonts. It stores a single instance of each bitmap in either a shared heap or in eXecute In Place (XIP) ROM and provides clients with read and (when appropriate) write access. </shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody><p>RAM-based fonts and bitmaps are reference counted and retained in RAM while they are being used. When they are no longer required they are automatically deleted. </p> <section><title>Key terms</title> <dl><dlentry><dt>Bitmap</dt> <dd><p>A two-dimensional (2D) buffer (in memory) that contains the color values for individual pixels and is encapsulated by the <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita"><apiname>CFbsBitmap</apiname></xref> class. </p> </dd> </dlentry> <dlentry><dt>Extended bitmap</dt> <dd><p>A bitmap that contains data compressed using proprietary formats. </p> </dd> </dlentry> <dlentry><dt>Raster image</dt> <dd><p>A data structure representing a rectangular grid of pixels. Scaling raster images usually leads to a loss of quality. </p> </dd> </dlentry> <dlentry><dt> Vector image</dt> <dd><p>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. </p> </dd> </dlentry> <dlentry><dt>Rasterization</dt> <dd><p>The process of converting vector image drawing instructions into a raster image that can be displayed on the screen. </p> </dd> </dlentry> <dlentry><dt>Scan line</dt> <dd><p>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. </p> </dd> </dlentry> </dl> <p>For font-related terms, see <xref href="GUID-90644B52-69D7-595C-95E3-D6F7A30C060D.dita">Font and Text Services Collection Overview</xref>. </p> </section> <section><title>Architectural relationships</title> <p>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. </p> <p>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 <xref href="GUID-E5B29AC0-4953-385F-84C5-13EE6CB77D46.dita"><apiname>RFbsSession</apiname></xref> and stores it in Thread Local Storage (TLS). Client-side font and bitmap classes such as <xref href="GUID-DE966D8B-6E00-39B6-B136-6CF29EA384D3.dita"><apiname>CFbsFont</apiname></xref> and <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita"><apiname>CFbsBitmap</apiname></xref> 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.) </p> <p>The Font and Bitmap Server contains the font store, which is a separate DLL provided by the <xref href="GUID-B798C19D-4030-564A-A208-D84738259D72.dita">Font Store (FntStore) component</xref>. Client-side access to the font store is through <xref href="GUID-5E287BF6-08C1-36A2-9085-F6B61CC52550.dita"><apiname>CFbsTypefaceStore</apiname></xref>. </p> </section> <section><title>Description</title> <p>The Font and Bitmap Server is a singleton process that owns fonts and bitmaps. <xref href="GUID-DE966D8B-6E00-39B6-B136-6CF29EA384D3.dita"><apiname>CFbsFont</apiname></xref> and <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita"><apiname>CFbsBitmap</apiname></xref> 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. </p> <fig id="GUID-51E1E299-6F2C-561F-8009-E4AF2B58A745"><image href="GUID-C3D0BA4A-AEC5-5002-916E-CB3F9FE5AC27_d0e200042_href.png" placement="inline"/></fig> <p>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. </p> <p>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. </p> </section> <section><title>API summary</title> <p>The Font and Bitmap Server presents a conventional client API through <xref href="GUID-E5B29AC0-4953-385F-84C5-13EE6CB77D46.dita"><apiname>RFbsSession</apiname></xref>, which represents the handle to a server-side session. The classes <xref href="GUID-DE966D8B-6E00-39B6-B136-6CF29EA384D3.dita"><apiname>CFbsFont</apiname></xref> and <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita"><apiname>CFbsBitmap</apiname></xref> are client-side representations of font and bitmap classes. </p> <ul><li id="GUID-80C1D158-E216-57E2-BB6E-1CD8C208FC92"><p>The <codeph>CFbsFont</codeph> class represents fonts managed by the Font and Bitmap Server, both bitmap fonts and OpenType fonts. </p> </li> <li id="GUID-D0629C81-48F5-5A9F-9D63-EC5B9D5D624B"><p>The <codeph>CFbsBitmap</codeph> 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 (.<filepath>mbm</filepath>) file or created as off-screen bitmaps, and then blitted to a window. For XIP ROM-based bitmaps, <codeph>CFbsBitmap</codeph> provides facilities for accessing the data. </p> </li> </ul> <p>The Font and Bitmap Server is unusual in that the <codeph>RFbsSession</codeph> is stored in client-side thread local storage (TLS). The constructors for <codeph>CFbsFont</codeph> and <codeph>CFbsBitmap</codeph> 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. </p> <p>The <codeph>RFbsSession</codeph> is created for clients by the Window Server’s client-side API when a Window Server session, <xref href="GUID-643DDA78-C7A7-386D-AB3F-8710141DDDA9.dita"><apiname>RWsSession</apiname></xref>, is constructed. A Window Server client is therefore also a client of the Font and Bitmap Server. </p> <p>When a client calls, for example, the <xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita#GUID-0AEE5955-C530-35F1-A904-69183331B294/GUID-1A360BAF-D2EF-3D96-8E6A-C399631EFBB9"><apiname>CWindowGc::DrawBitmap()</apiname></xref> function, the handle number of the bitmap is passed to the Window Server through inter-process communication (IPC). Like all <xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita"><apiname>CWindowGc</apiname></xref> 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 <xref href="GUID-22093E74-EFE7-5642-93DE-1573E18F7C08.dita">Window Server rendering loop</xref>. Consider the scenario where an application calls <xref href="GUID-0AEE5955-C530-35F1-A904-69183331B294.dita#GUID-0AEE5955-C530-35F1-A904-69183331B294/GUID-1A360BAF-D2EF-3D96-8E6A-C399631EFBB9"><apiname>CWindowGc::DrawBitmap()</apiname></xref> 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, <xref href="GUID-E5B29AC0-4953-385F-84C5-13EE6CB77D46.dita"><apiname>RFbsSession</apiname></xref> 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 <xref href="GUID-683A1D42-2764-3EB7-BD19-9E12559199AB.dita"><apiname>CFbsBitmap</apiname></xref> 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. </p> </section> </conbody><related-links><link href="GUID-A03FB1BF-F67B-519D-A904-74CA3F8375D9.dita"><linktext>Font and Bitmap Server Collection</linktext> </link> <link href="GUID-30CAE438-6CC7-5532-8727-781B8E83574A.dita"><linktext>Heap Locking in the Font and Bitmap
                Server</linktext> </link> <link href="GUID-90644B52-69D7-595C-95E3-D6F7A30C060D.dita"><linktext>Font and Text Services Collection
                Overview </linktext> </link> <link href="GUID-416A3756-B5D5-5BCD-830E-2371C5F6B502.dita"><linktext>Font Store Component Overview </linktext> </link> </related-links></concept>