xc/lib/font/FreeType/ in "XORG-RELEASE-1"-branch differs fromXfree86 trunk...

[Roland Mainz]

Keith Packard wrote:
> > Can you please restore the original code ? I guess the current version
> > in the "XORG-RELEASE-1"-branch will likely result in a horrible
> > disaster.
> 
> I don't see a horrible disaster here; I see a performance problem for an
> unexpected usage pattern (fonts with embedded bitmaps that aren't used).
> I don't think there is any functionality that will be impacted.

1. Many TTF fonts for CJK languages have both bitmaps and outlines. They
are affected by the change, right ?
2. Can you explain this:
Without your patch:
-- snip --
% (DISPLAY=:40 time -p ./a.out)
# Start.
# stat: num_fonts=2405, num_fonts_loaded=2359
# Done.
real 71.59
user 0.18
sys 0.69
-- snip --
With your patch applied:
-- snip --
% (DISPLAY=:40 time -p ./a.out)
# Start.
# stat: num_fonts=2405, num_fonts_loaded=2359
# Done.
real 95.29
user 0.45
sys 0.96
-- snip --
(the values remain pretty much stable over ten iterations), I have
attached the test application to this email. Test server was "Xvfb",
test machine an Athlon 64FX with 1GB RAM, only TTF fonts were used in
the font path except /usr/X11R6/lib/X11/fonts/misc/.

Per above results I consider this as a serious performance regression
(for application like Mozilla which load MANY fonts the problem may be
worse that the 25sec difference in the very simple testcase used above)
- it seems you've undone a large chunk of Chisato Yamauchi's performance
work.

> And, if we do ship the code, I expect the FreeType API will never be
> fixed, so we'll be stuck in the next release at the same place.

That's unlikely. We can simply link that stuff statically into the
Xserver and then don't have any problems with that.

> Actually, I was thinking about this -- you want to know when bitmaps are in
> use; it seems like that's trivial -- pull a single glyph from the font and
> see if you get back an outline or a bitmap.  Assume that the font will
> uniformly return bitmaps or outlines; after all, that's what's being
> assumed in the current code.  That should be essentially as fast as the
> original code without breaking the API.

Chisato - would that way work ?

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 2426 901568 FAX +49 2426 901569
 (;O/ \/ \O;)
-------------- next part --------------

#include <stdlib.h>
#include <stdio.h>
#include <limits.h>

#include <X11/Xlib.h>

int main(void)
{
  int       i,
            num_fonts = 0,
            num_fonts_loaded = 0;
  char    **fontnames;
  Display  *dpy;

  puts("# Start.");

  dpy = XOpenDisplay(NULL);
  if (!dpy)
    return EXIT_FAILURE;
  
  fontnames = XListFonts(dpy, "-*", INT_MAX, &num_fonts);
  if (!fontnames || !num_fonts)
    return EXIT_FAILURE;

  for( i = 0 ; i < num_fonts ; i++ ) {
    XFontStruct *info = XLoadQueryFont (dpy, fontnames[i]);
    if (info) {
      XFreeFont(dpy, info);
      num_fonts_loaded++;
    }
  }
  
  XCloseDisplay(dpy);
  
  printf("# stat: num_fonts=%d, num_fonts_loaded=%d\n",
         num_fonts, num_fonts_loaded);

  puts("# Done.");
  return EXIT_SUCCESS;
}