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

We have just posted a paper "Xft2 and STSF: A Side By Side 
Comparison" on our web site: 

http://stsf.sourceforge.net/docs.html

Before we continue with this discussion please take a look 
at it since it addresses a lot of issues we've been talking
about. 


Regards,
AG


On Thu, Mar 27, 2003 at 01:54:21AM -0500, Havoc Pennington wrote:
> 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
> _______________________________________________
> Forum mailing list
> [email protected]
> http://XFree86.Org/mailman/listinfo/forum

-- 
Alexander Gelfenbain, Sun Microsystems, Inc.
+1 (408) 635-0612