<?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 id="GUID-71DADA82-3ABC-52D2-8360-33FAEB2E5DE9" xml:lang="en"><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 id="GUID-0EA6C402-744F-48E4-AF4A-77766EEAC550"><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 id="GUID-B05FE02D-4138-46C0-9572-63F77B0B8375"><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 id="GUID-23033D81-6D4C-4E04-A5E6-B11832266F51"><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_d0e261785_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 id="GUID-8E41C4C2-8983-4B88-9206-99826C61140E"><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>