[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ftx font driver [Re: Low redisplay performance (23 regression)]

From: Kenichi Handa
Subject: Re: ftx font driver [Re: Low redisplay performance (23 regression)]
Date: Thu, 23 Apr 2009 20:22:10 +0900

In article <address@hidden>, YAMAMOTO Mitsuharu <address@hidden> writes:

> > As ftx font driver is not used by default on any platforms, it is
> > not tested well and I myself don't remember the code well.

> There might be the case that the Xft library is not installed, does
> not have a sufficient version, or not found by configure for some
> reasons (e.g., PKG_CONFIG_PATH is not set appropriately).  In such
> cases, the ftx font driver is selected as a default.  Of course, you
> can reproduce such a situation with --without-xft.

Ah, you are right.  I should have written "usually" instead
of "by default". 

> The result of time profiling using Shark.app indicates that
> FT_Load_Glyph called from ftfont_text_extents takes much time and
> calculates font metrics repeatedly without caching.  In particular,
> it's really slow if the font is actually in a gzipped PCF format.

>       0.0%    22.2%        FT_Load_Glyph      
>       0.1%    22.0%         PCF_Glyph_Load    
>       0.0%    21.8%          FT_Stream_Seek   
>       0.0%    21.8%           ft_gzip_stream_io       
>       0.0%    21.8%            ft_gzip_file_io        
>       0.0%    21.8%             ft_gzip_file_skip_output      
>       21.3%   21.8%              ft_gzip_file_fill_output     
>       0.5%    0.5%                ft_gzip_file_fill_input     

Ummm, I didn't realize this calling sequence.  I agree that
we surely need some kind of caching mechanism.  But, it
seems that FreeType itself has that mechanism called "Cache
Sub-System".  Perhaps, we should use it.

Kenichi Handa

reply via email to

[Prev in Thread] Current Thread [Next in Thread]