Re: Fonts

["Liam R. E. Quin" <liam holoweb net>]

On Tue, 2005-08-02 at 10:35 +1000, Russell Shaw wrote:

> I was wandering if every time a gtk app prints some text, the instructions
> for each character to print are sent as 1 byte, or 4 bytes like utf-8 or
> whatever (eg, 0x61 for 'a') so that the text rendering thing on the server
> side knows which glyph to render, or if there are fonts where each *bitmap*
> for a character is sent from the client to the server.

It's rather more complex than that.

In the simplest case, an instruction to draw at a given location
is sent using the X protocol, and the operands include the graphics
context to use, the drawable to draw onto, the x and y coordinates
(all as 16-bit integers I think, although compression is used in
some circumstances) followed by the 16-bit length of the string,
followed by the string, and the server maps each character of the
string to the corresponding bitmap in a font.

However, it turns out to be faster and more efficient to render
the fonts to bitmaps on the client.  The first time each character
is used it is sent to the server as a bitmap, but subsequently
it is reused.

One reason that this is more efficient is that in order for the
client to tell the server to use the server-side fonts, the
server has to send the full font metrics to the client -- the
bounding box of each character, etc. -- and this is a lot of
data.

> Is pango running on the client side, or the server side?
client.

> A previous post mentioned "font caching". I was wandering if gtk can be
> speeded up.
For any particular application there may be ways to speed up rendering,
but in general a lot of effort has already been put into making it
at least reasonably fast.  Have you written a program that's too
slow?

One thing to check is that your DISPLAY variable is set to :0.0 and
not to the full hostname -- this can make a significant difference on
slow systems.

Otherwise it's hard for me to guess where you might have performance
problems: it's necessary to measure.

Liam

Liam Quin,
http://www.holoweb.net/~liam/
http://fromoldbooks.org/