xc/lib/font/FreeType/ in "XORG-RELEASE-1"-branch differs
fromXfree86 trunk...
Roland Mainz
roland.mainz at nrubsig.org
Sun Mar 14 17:27:37 PST 2004
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;
}
More information about the release-wranglers
mailing list