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

On Thu, Mar 27, 2003 at 01:50:05PM -0800, Alexander Gelfenbain wrote:
> 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. 
> 

Yes, this document was in part written with feedback from Owen and I,
though it seems to have evolved in a more STSF-friendly direction over
time.


First, on a high level: the document is missing the point that
fontconfig/Xft2 are already widely deployed for a year or so, and STSF
is still in part not implemented. This means the two technologies are
not on a level playing field. For STSF to be a good idea, you have to
not only show that it is better in some absolute sense, but also that
it is better enough to deprecate fontconfig/Xft2 only a year after
deploying them and redo massive amounts of work. You also still have
to show the server-side stuff working with good performance and
real-life significant memory savings.


Second, to be constructive, here is an IMHO more realistic approach to
what you want to do:

 - Create a GLib-independent text layout API that maps closely to the
   PangoLayout API, so we can re-backend PangoLayout without breaking
   Pango. Work closely with Damon Chaplin, Owen, and others who are
   actively developing new Pango functionality.

 - Look at iterative freetype improvements to support proprietary
   rasterizers.

 - Look at simpler fontconfig/Xft extensions to address the memory
   usage issue, and analyze/present real-world profiles of entire
   desktops with applications running to show that fonts are 
   the best place to focus for memory usage problems.


Third, I'll try to extract some of the comparison issues and address
those.

1. Proprietary rasterizer plugins.

   I don't personally think we should care about this, but if 
   we do, it should be trivial to extend freetype to support them.
     
2. Neutral with respect to X11/operating system/etc. 

   freetype and Pango also are. I can understand some hesitancy to
   use GLib across all platforms/applications, and I can thus see 
   an argument for a PangoLayout equivalent library. *However*, 
   replacing fontconfig is insanity. (Just as replacing the standard
   font configuration on Windows would be. You need to use the
   standard system font configuration, not your own.)

   The paper says STSF "will be able to use fontconfig to discover
   fonts." That isn't good enough. It needs to require fontconfig when
   running on UNIX, and needs to use fontconfig for font matching, 
   always.

   In short, platform-independent font configuration is broken. You
   should use the platform's existing font configuration.

3. CSS font matching algorithm.

   Using this is an important feature of fontconfig.  Unclear to me
   whether STSF uses it.

4. Server-side text layout helps with SunRay memory usage etc.

   I think we've already elaborated at length why we think this is 
   bad.

   A point not yet addressed is sharing cache between multiple users,
   not just multiple apps. However, when we consider the typical size
   of each user's desktop login session (128 megabytes is not a crazy
   number), it's hard to understand why we should focus optimization
   efforts on areas that cause oceans of porting pain and performance
   hits.

   Question: do you have server-side PangoLayout up and running with
   GNOME where we can try it out? If not, when will you? Because I'm
   going to need to see this to believe it can be done with acceptable
   performance and real memory wins at the same time.

5. Porting Mozilla and GNOME to STSF is a LOT of work. *LOT* of work.
   PangoLayout API is already used extensively.

   As I pointed out last night, the Xft compat layer is a non-answer
   to this concern, because if you're just reimplementing Xft there's
   no point.

6. In all the claims here about abstraction, you're ignoring that GTK+
   and Qt already provide the level of abstraction you're talking
   about. Most apps use only GTK+/Pango and Qt APIs, *not* Xft
   directly. Which is as it should be. In fact we moved from core X
   fonts in GTK+ 2.0 to fontconfig/Xft in GTK+ 2.2 while maintaining
   ABI. The solution needed here is a toolkit implementation detail
   more than anything else.

7. The sentence "STSF is fully compatible with the requirements of the
   GNOME desktop" is plain old bullshit. Owen maintains GTK+, and I am
   one of the longest-standing and most active GNOME developers.  We
   are telling you right now that the mere fact that STSF is
   *different* from what the open source toolkits have already adopted
   undermines our most important requirement, which is standardizing
   on a single font configuration system for UNIX, and fontconfig has
   already been largely deployed as that system. We are also telling
   you that moving away from PangoLayout is so hard that it's
   basically impossible.

8. Performance evaluation.

   "Full benchmarks of STSF have not yet been created."
   
   That would be because STSF isn't finished yet, I gather. How do you
   know it even uses less memory, all things considered?

   After all, core X fonts also theoretically used less memory. Until
   the de facto reality became that every app had to suck them off the
   server anyway... something STSF does not really fix, as far as I
   can see.


I hope to see STSF reconsidered to require fontconfig at a minimum. 

I think a lot of the server-side stuff is a bad idea, and I don't see
who is going to use the text layout engine (unless it maps cleanly to
the PangoLayout and other toolkits' APIs and is developed in close
cooperation with GTK+/Qt/etc.), but if you want to work on those it's
not really actively *harmful* - as long as you use fontconfig.

But if you don't use fontconfig, you are causing everyone a world of
hurt. We need to standardize on fontconfig. It's good enough. It
works. It solves a huge user-visible problem. Creating confusion about
whether to use fontconfig is *bad*.

Havoc