Re: Pango Speed
- From: "zitan" <zitan mediasculpt net>
- To: gtk-i18n-list gnome org
- Cc:
- Subject: Re: Pango Speed
- Date: Wed, 5 May 2004 21:57:11 -0400
Hey Owen,
Thanks a lot for the response :-)
>> Can anyone tell me if a second is slow for creating a fontmap, setting the context and getting the pixel width?
>> What is causing the time length? Is it because of creating a new fontmap object and setting the resolution?
>On my (1Ghz) machine Pango can get the width of ~25,000 10 character
>strings in a second.
>The two things that are going to be slow are:
> - Initializing fontconfig initially
> - Creating a new fontmap
I found that laying out a new font seemed to definately have an overhead.
>1 second is pretty slow though in general even for this startup
>overhead. One thing you should try is running 'fc-cache -f' (as root)
>... it may be that fontconfig is having to go through all your fonts
>each time it starts up. Reducing the number of fonts on your system will
>also reduce fontconfig startup time overhead a lot.
After running fc-cache -f my script is now practically instaneous and even without rolling out the single pango call my site is considerably faster ... wow that is just awesome !!!
>> If so is there some way I could create a object once, and then reuse this object? Is there anything I can do to optimise the code or my pango installation?
>This is really a question of web programming. Perhaps you want to write
>a persistant server that does the Pango computations and just make your
>CGIs talk to that.
Yeah I had a crack at something like this by calling Pango only once per document view which would help things a lot (and creating the fontmap once etc.). To have persistent threads holding open pango objects would be complex because firstly you would need to access pango directly (using swig) and then you would need to persist these objects and pass them around as resources. This is doable in php (with singleton which SRM implements), but is very involved. I think I'll stick to updating my font cache regularly instead for now :-)
Thanks again,
Z.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]