Around 9 o'clock on Feb 23, Alan Coopersmith wrote:
> It is our belief that leaving font rendering on the server side will be
> more efficient than sending the bits over from the client side. Of course,
> we can't prove this until we've actually done it, so we don't know for
> sure.
I'm excited about having another new API for text layout; the problems are
hard, and I think we have a long ways to go before the right API becomes
obvious. More implementations will really help this issue. However, I
feel that the underlying infrastructure supporting the ST API is moving in
the wrong direction.
XST vs Xft:
I believe ST could easily be completely implemented on top of the existing
Xft/fontconfig/FreeType library APIs for accessing fonts and their related
data. This would provide significant benefits for everyone:
+ ST implementation can progress independently of any other X work.
+ ST will run efficiently on current XFree86 servers with no
need to wait for the two year deployment cycle for new X
extensions.
+ ST will run on all X servers and include AA/LCD text on
legacy TrueColor servers
+ ST-based applications will share font configuration with all
other Xft/fontconfig-based systems (Qt, Gtk+, Mozilla)
+ Applications can migrate to ST-based text output incrementally,
confident that their font selections will remain consistent
across the user interface.
+ No protocol dependencies on font capabilities; migrating to
new unimagined font formats can happen as quickly as a new
library can be made available.
Using a custom extension with core-fallback code would cause many problems:
- Yet another X extension to deply and maintain.
- Yet another font configuration and customization mechanism
- Unresolved issues of system and network performance
- Protocol may restrict future font capabilities.
Text Performance and the Render Extension:
When considering client-side text during the design of the Render
extension, I did a quick calculation to show that for non-AA text, Render
would use no more bytes on the wire than the core protocol -- the core must
transfer the metrics for every glyph in the font to the client so that it
can perform layout. Those metrics consume 16 bytes per glyph. A typical
12 pixel font consumes some 20 to 30 bytes per glyph image. Because core X
must transmit *all* of the metrics for the font, and because most text uses
less than half of the glyphs in any particular font, even in 8-bit
encodings like Latin-1, it was evident that client-side text wasn't a crazy
idea. AA text doesn't increase the size of the data significantly; our 12
pixel font may now consume some 50 bytes of data per glyph.
Once I had the protocol up and running and had ported some real
applications, I made some measurements comparing server-side core text to
client-side Render text. The data I've collected indicate that even for
simple text, the Render extension is more efficient than the current core
protocol. While the total bandwidth consumed rose modestly when switching
from core to AA text, that increase was more than offset by the decrease in
the amount of time applications spent waiting for data from the X server,
both to get the metrics for each font, and also in inquiries about the set
of available fonts.
>From my understanding of how the XST extension works, adding sophisticated
layout to the mix will require many more round trips as the client can no
longer compute display metrics for text locally. It seems that just to
center text in a button will require a round trip to the X server each time
the text is altered.
Here's a presentation I did about why LBX was a failure:
http://www.xfree86.org/~keithp/talks/lbxpost/
The data in this presentation shows that bandwidth is not a serious problem
for X performance, except for images. The real performance bottleneck has
always been latency -- here's a slide from that talk:
http://www.xfree86.org/~keithp/talks/lbxpost/slide-16.html
The numbers presented are for a synthetic network with 30ms RTT and
300Kbps bandwidth. Faster networks don't significantly alter the ratio
between these two factors (100Mb network has about .1ms RTT, a factor
of 300 for both values). Note that application startup time for the
core-text applications (Netscape and the Gimp) are both dominated by the
application simply waiting for data from the X server; the wire is idle
around 70% of the time.
Once core text applications are started, they run relatively asynchronously
reducing the latency effect, this makes them relatively efficient after
startup.
By placing all of the text management within the application address
space, the Render extension eliminates all latency concerns during
application startup and execution -- there is no information that the X
server has other than that provided by the client; Render clients are
faster off the line and no slower during execution than core clients.
The only drawback of the Render model is that the glyph images must be
transmitted from the client to the server; my measurements demonstrate
that this effect is mitigated by eliminating the glyph metrics that
currently transit from the X server back to the client for core text;
the metrics may be slightly smaller than the typical AA text image, that
is more than compenstated by the fact that Render sends only the glyphs
actually displayed while the core text requests must deliver metrics for
the entire font.
As ST shares some architecture in common with core X text, I believe this
analysis is relevant to the discussion of the merits of an XST extension.
This is completely separate from the discussion of the ST system as a
whole; on that score, I'm much in favor of any new implementations of high
quality text layout.
Conclusions:
The ST system looks very useful, and clearly much thought has been applied
to how applications can effectively use the API to produce truely
international output. To effectively display the resulting output
efficiently clearly requires additions to the X server, I submit that
the existing Render extension provides a better model than any server-side
implementation can, especially in a heterogeneous environment where a
single vendor doesn't control the applications, the libraries and the X
server itself.
There are many existing systems using Xft/fontconfig/Render. Qt3, Gtk+ 2.0
and Mozilla are all running today. This should instill some confidence
that ST could be ported to this API without significant effort or any loss
of functionality.
Let's use the ST teams expertise in international text layout to its
fullest and leave the underlying font management to existing mechanisms.
Keith Packard XFree86 Core Team Compaq Cambridge Research Lab
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
