Around 9 o'clock on Nov 29, Brian Stell wrote:
> The choice to put X font handling on the server as opposed > to the client has some advantages (feel free to add more): > > sharing a common resource => memory savings > > the pixels are at the X server => minimal network bandwidth Of course, the most obvious reason is that when X was developed, it was commonly expected that the graphics API would provide a list of fonts -- printers inclued embedded fonts, text-mode terminals had embedded fonts. All major window systems from that era placed font handling below the API. > The choice to put X font handling on the server as opposed > to the client has some disadvantages (feel free to add more): One of the most severe problems we have today is that modern fonts have hundreds or thousands of glyphs. The core X font mechanism requires that all of them be rasterized before the first one can be used; this takes a long time. Replace that with some incremental mechanism and the client will execute dozens of round trips as new glyphs are needed -- the metrics cannot be computed without rasterization and the client must have the metrics before it can figure out how to position them. With a hundred (or so) bitmapped glyphs, the choice of where to store the fonts is largely irrelevant; either side would work equally well and centralizing them within the display server doesn't seem like the wrong solution. > server-side font handling: > most memory efficient > most network bandwidth efficient Actually, server-side font handling has neither of these benefits -- I've measured the network traffic generated by client-side fonts and have found that for typical modern applications, the trade off of transmitting some of the bitmaps vs transmitting all of the metrics is a wash. And that's when transmitting 8bpp alpha maps instead of 1bpp glyphs. As for memory, the storage requirements are equivalent -- the server must hold metrics and glyph data and the client must hold metrics. Add in incremental rasterization and the memory savings are clearly in favor of client-side rasterization. The one significant savings available for server-side rasterization is in CPU time. Sharing the cost of rasterizing glyphs is trivial when the server does the work and rather hard when done in the client. There are mechanisms in the Render extension to make this possible, but I don't have any plans to take advantage of them. > client-side font handling: > fastest way to get new features in To some extent; this just means that clients are in control of their fate. Place fonts in the X server and you can add features to *all* applications in one place. In a world without shared libraries, this is the one way to share code improvements. > the X server currently renders the entire set of characters which uses a > lot of server memory (anyone know if Xfs does incremental rasterization?). > This can be fixed (and should be fixed) It really can't be fixed -- the entire set of metrics must be delivered to the client before a single glyph can be drawn, the only way to compute metrics is to rasterize the glyphs. It would take a change in the protocol and an application-visible change in Xlib to make this possible. > I don't know whether Keith directly considered this issue when he designed > Xft or just thought "I can make a big improvement in X fonts and get it > into the users hands (without a protocol change)". Juliusz Chroboczek and Raph Levien made the suggestion to eliminate server-side fonts during the Render extension design and it was an epiphany for me -- I'd been struggling with these issues and suddenly they all just disappeared. > Xft is relatively memory efficient since apps > only generate per-glyphs metrics for the glyphs > they actually use and (assuming I understand this) > the glyphs at the server are shared. The Xft API also allows it to discard infrequently used metrics and glyphs so that memory usage can be controlled very tightly. A small change in the API will permit it to do the same with the underlying FreeType face. The X server actually shares *all* identical glyphs -- it has a single giant pool of glyphs that all clients and all glyphsets (fonts) reference. Keith Packard XFree86 Core Team SuSE, Inc. _______________________________________________ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
