[Fonts] libfreetype-xtt2 bench
Hi,
I've switched from X-TT to libfreetype-xtt2. Then I investigated
the performance of libfreetype-xtt2.
The following is simple code(bench.c) for testing:
#include
#include
Display* dis=NULL;
int main( int argc, char *argv[] )
{
dis=XOpenDisplay(NULL);
XLoadQueryFont( dis, argv[1] );
return 0;
}
COMMAND:
% time ./bench "-bitstream-cyberbit-medium-r-normal--0-0-0-0-p-0-iso10646-1"
RESULTS:
[X-TT 1.4.2]
No TTCap options:
0.01s user 0.00s system 0% cpu 3.024 total
With "vl=y" option
0.00s user 0.00s system 0% cpu 2.531 total
With "vl=y:fc=0x3400-0xe7ff:fm=0x5a00" option
0.00s user 0.00s system 0% cpu 0.155 total
[libfreetype-xtt2 version 1.0b]
No TTCap options:
0.00s user 0.00s system 0% cpu 3.491 total
With "vl=y" option
0.00s user 0.00s system 0% cpu 0.045 total
With "vl=y:fc=0x3400-0xe7ff:fm=0x5a00" option
0.00s user 0.00s system 0% cpu 0.017 total
STANDARD:
"-b&h-luxi serif-medium-r-normal--0-0-0-0-p-0-iso8859-1"
without TTCap option
[X-TT 1.4.2]
0.00s user 0.00s system 0% cpu 0.013 total
[libfreetype-xtt2 version 1.0b]
0.00s user 0.00s system 0% cpu 0.016 total
The xtt2's "vl=y" is super-fast. It seems that libfreetype's
simple cache mechanism works fine.
If you want the very lazy method(vl=y) as default when handling
large charset, define DEFAULT_VERY_LAZY at top of ftfuncs.c as
follows:
#define DEFAULT_VERY_LAZY 2 /* Multi-byte only */
This macro can be used in version 1.0b.
1.0b patch -> http://x-tt.sourceforge.jp/
EE> > > Two further issues:
EE> > > 1. would it be possible to convert xtt to use freetype2 instead
EE> > > of freetype1? This would allow us to remove the freetype1 sources
EE> > > from the tree.
EE>
EE> Would it be possible to do that?
EE>
EE> > Why do we persist in X-TT? The reason is that "libfreetype.a"
EE> > does not useful at all in CJK. Especially the following two points are fatal.
EE> >
EE> > - Handling a proportional multi-bytes fonts is too slow.
EE> > (The loading speed of libfreetype.a is 20 times slower than
EE> > that of X-TT 1.4; I show a benchmark in next email.)
EE> >
EE> > - The modification of a font(such as auto italic and double striking, etc.)
EE> > cannot be used at all.
EE> >
EE> > That is, "libfreetype.a" should also have all options of "TTCap".
EE>
EE> I would agree that these are valid issues.
EE>
EE> Has anybody looked at merging these XTT functionalities into the
EE> freetype module?
As you said, I've worked for merging X-TT functionalities
and various fixes. And I've released libfreetype-xtt2 patch
version 1.0b.
Would you accept our libfreetype-xtt2 patch? If our patch
is accepted before XFree86-4.4 release, I think that you will
be able to remove freetype1 sources from XFree86's tree at
XFree86-4.5 release.
By the way, did anybody fix the problem of the omega-serif
fonts? Mike FABIAN said that
-altsys-omegaserif88591-medium-r-normal--0-0-0-0-p-0-iso10646-1
-altsys-omegaserif88592-medium-r-normal--0-0-0-0-p-0-iso8859-2
didn't work. But they can be loaded on libfreetype-xtt2.
Is this our fix? or not?
Chisato Yamauchi
After X-TT Project
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] libfreetype-xtt2 bench
From: Chisato Yamauchi <[EMAIL PROTECTED]> Subject: [Fonts] libfreetype-xtt2 bench Date: Mon, 20 Oct 2003 02:05:58 +0900 (JST) Message-ID: <[EMAIL PROTECTED]> > Would you accept our libfreetype-xtt2 patch? If our patch > is accepted before XFree86-4.4 release, I think that you will > be able to remove freetype1 sources from XFree86's tree at > XFree86-4.5 release. and all "fontcache" stuffs will be able to be removed, too. -- Takuya SHIOZAKI ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] libfreetype-xtt2 version 1.0 released
Chisato-san, I am sincerely sorry for not checking your code right now -- I am unfortunately a little busy currently. I will read it as soon as I've got some time, and I'll get back to you. Sincere regards, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] libfreetype-xtt2 bench
CY> As you said, I've worked for merging X-TT functionalities CY> and various fixes. And I've released libfreetype-xtt2 patch CY> version 1.0b. CY> Would you accept our libfreetype-xtt2 patch? If our patch CY> is accepted before XFree86-4.4 release, I think that you will CY> be able to remove freetype1 sources from XFree86's tree at CY> XFree86-4.5 release. Chisato-san, I am very glad to see TTCap implemented in the FreeType backend. The main point is that I consider core fonts to be obsolete -- client applications, especially internationalised ones, should move to Xft. This is the reason why I have basically kept the features of the FreeType backend frozen for a long time. We need to seriously consider whether inclusion of your patch goes against this goal. You'll understand that this is not a discussion that we can have before I've read and fully understood your code. Please accept my apologies for being slow, Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] libfreetype-xtt2 bench
On Sun, Oct 19, 2003 at 09:42:55PM +0200, Juliusz Chroboczek wrote: >CY> As you said, I've worked for merging X-TT functionalities >CY> and various fixes. And I've released libfreetype-xtt2 patch >CY> version 1.0b. > >CY> Would you accept our libfreetype-xtt2 patch? If our patch >CY> is accepted before XFree86-4.4 release, I think that you will >CY> be able to remove freetype1 sources from XFree86's tree at >CY> XFree86-4.5 release. > >Chisato-san, > >I am very glad to see TTCap implemented in the FreeType backend. > >The main point is that I consider core fonts to be obsolete -- client >applications, especially internationalised ones, should move to Xft. That's an issue to take up with application developers. We still have users with applications that require 8-bit PseudoColor visuals. >This is the reason why I have basically kept the features of the >FreeType backend frozen for a long time. > >We need to seriously consider whether inclusion of your patch goes >against this goal. You'll understand that this is not a discussion >that we can have before I've read and fully understood your code. Achieving the goal of a single freetype backend without taking away functionality that people are actually using is a good one, regardless of anything else. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] libfreetype-xtt2 bench
>> The main point is that I consider core fonts to be obsolete -- client >> applications, especially internationalised ones, should move to Xft. DD> That's an issue to take up with application developers. Isn't that what we are doing? Let me reformulate this: I do not think that adding functionality to core fonts is a good way to expend developper time, particularly when I am the delopper in question. Especially so in October. >> We need to seriously consider whether inclusion of your patch goes >> against this goal. You'll understand that this is not a discussion >> that we can have before I've read and fully understood your code. DD> Achieving the goal of a single freetype backend without taking away DD> functionality that people are actually using is a good one, regardless DD> of anything else. I agree in principle. Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts] libfreetype-xtt2 bench
On Sun, Oct 19, 2003 at 11:29:30PM +0200, Juliusz Chroboczek wrote: >>> The main point is that I consider core fonts to be obsolete -- client >>> applications, especially internationalised ones, should move to Xft. > >DD> That's an issue to take up with application developers. > >Isn't that what we are doing? > >Let me reformulate this: I do not think that adding functionality to >core fonts is a good way to expend developper time, particularly when >I am the delopper in question. Especially so in October. None of that matters if others find that they need functionality that you disagree with in order to use the applications that they have today to their satisfaction. If you personally choose not to meet their needs (which is entirely up to you, and entirely reasonable), someone else might. I'm not really interested in seeing contributions rejected solely on the premise that accepting them would reduce the impetus for application developers to move in a particular direction. This isn't what I would call a convincing technical argument if I were such an application developer. So, no, I don't think that is what you are doing here. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
