Server side text layout (was Re: [forum] some XFree86 5.0 questions...)

[Havoc Pennington]

On Wed, Mar 26, 2003 at 09:29:43PM -0800, Alexander Gelfenbain wrote: 
> I believe in abstraction and encapsulation. STSF implements 
> a text layout object. It abstracts out its implementation 
> that can be either server-side or client-side.

You can't categorically believe in abstraction and encapsulation -
both of those things have a cost. You have to use them when
appropriate, when the abstraction penalty (in performance and
complexity) is going to get you somewhere. This is the principle of
KISS.

In our practical experience deploying solutions in this area over the
last couple years, Pango is already over the performance and
complexity threshold (both internally and externally) and is one of
the larger application developer complaints about GTK+ 2.x in those
respects. It's more complex and slower than just mapping 1 char to 1
glyph and writing the glyphs to the screen, which is what people are
used to.

It's not *good* to add extra complexity when the code you have is
already functional enough, and the main complaint people have is that
its abstraction penalty is already too high. To justify that you need
to have a better reason than conceivably saving 100K-200K per app when
I'm currently using 1500K or more to run a trivial app such as
gnome-calculator or kcalc and OpenOffice uses 37 megabytes.  You have
to have a better reason than slightly prettier API.

I'm sure if you spent all the effort going into STSF on fontconfig,
you could find a way to save the 200K that was a heck of a lot
simpler. If you want to trade performance for memory, what about just
compressing data? Shared memory? A trivial little per-user daemon that
caches font data and does nothing else? Clever data structures?  There
are lots of options.

Heck, for that matter, why not optimize something else that's probably 
much more easily optimizable. If the fontmap is 200K there's 1300K of
other stuff just in gnome-calculator.

There isn't even any reason to believe that STSF will use less memory,
once you count all the extra code in the client lib, the server, and
the caches you will need to make it perform sanely.

Look at Gnumeric. Pango's performance has already led Gnumeric to
cache hundreds of PangoLayout objects. Given this fact, does it save
more memory to a) optimize the code so you can avoid the cache or b)
make PangoLayout even slower. The cache isn't even a good solution,
because initial layout is still too slow.

> You are missing one point. Glyph vectors and client-side layout is
> not the only way to extend STSF layout processing. STSF layout is 
> implemented as a layout engine drop-in object (shared library.)
> The interface between STSF and layout engine objects is documented
> and custom layout engines can be written and dynamically installed,
> potentially without restarting the application or the ST Font Server.

So instead of calling a few client-side functions, apps have to write
a dynamically loadable module and install it on the server side, where
they don't even necessarily have filesystem access and the client and
server may be running different versions of the OS or different OS's
entirely.

I doubt having a couple dozen third-party DSOs loaded into my font
server is going to be conducive to stability.

We've just finished spending two years moving millions of lines of
code *that Sun has just shipped* over to fontconfig/Xft/Pango. Do we
want to do that again?

Will 200K per app even matter after 1-2 years to finish STSF, 2 years
to move GNOME over to it, and 1-2 years for OS vendors to deploy the
result?

The Xft compat layer doesn't count, as it doesn't get you the benefits
of STSF, it's just a reimplementation of Xft. STSF is only useful once
we move to it natively.

Havoc