Re: gtk+/tests/testtext Doesn't Run

Eric Mader <mader jtcsv com> writes:

> At 10:07 AM 8/14/2002, Eric Mader wrote:
> >At 10:31 PM 8/13/2002, Owen Taylor wrote:
> >> >
> >> > That didn't help... I rebuilt fontconfig, Xft, Pango and GTK+ by
> >> > re-running the config script and then doing "make" - should I have
> >> > done a "make clean" first?
> >>
> >>Shouldn't matter .. it will detect the new freetype headers.
> >>
> >>What might be useful is:
> >>
> >>  a) Does running 'fc-cache' as root show the same hang?
> >
> >Yes!
> >
> >>  b) If you run it the program under strace, what directory/file
> >>     does it hang on?
> >
> >Won't be able to get to this 'till next week...
> >
> >>Regards,
> >>                                         Owen
> While playing around w/ strace to see where the program was hanging, I
> noticed that if I let it run for about 7 minutes, it *does* come
> up... don't know what that means. Looking at the strace output, it
> looks like maybe it spends several seconds per font, which may explain
> why it takes so long. I've enclosed the strace log.
> Next I tried running fc-cache. This took about 7 minutes to run also,
> and now testtext comes right up. So, it looks like the problem has to
> do with missing font caches... What I don't understand is why this
> didn't happen on my RH 7.3 system. Could it be that the 7.3 installer
> runs fc-cache? (I assume that I have the same set of fonts on both
> systems since they were both installed using the 7.2 installation
> CDs..)

Hmm, are you sure that you upgraded FreeType on the 7.2 machine?
This is exactly the difference I'd expect between a machine
with FT_Get_Next_Char() (added in 2.0.9) and one without 
FT_Get_Next_Char(.) The one without FT_Get_Next_Char() would
take a really long time to compute the cached coverage information.


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