discuss-gnustep
[Top][All Lists]
Advanced

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

Re: Font substitution (Was: System fonts)


From: Kazunobu Kuriyama
Subject: Re: Font substitution (Was: System fonts)
Date: Sun, 29 Aug 2004 06:22:22 +0900
User-agent: Mozilla/5.0 (X11; U; Linux i686; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1

Alexander Malmberg wrote:

Since this seems to be a common request, I'll look at implementing this soon (I was going to say after the release, but with the delay, well, we'll see :).

Good news.

[snip]


* Performance
(for back-art, but most of it applies to back-xlib as well)

[snip]

Which characters you use in a text doesn't have any principle effect on the performance. However, there are a lot of caches involved, and that might have an effect. If you're only using latin1 text, you're probably just using 100 different characters, so you're pretty much guaranteed that any glyph metrics/bitmap/whatever you need will be in the cache. OTOH, if you're using chinese text, you might be using >1000 characters. This will either be slower (more cache misses and expensive recalculations), or use more memory (larger caches).

I don't know of any measurements of this, but I do know that getting glyph metrics used to be (before it was cached) a significant bottleneck in the layout process, so additional cache misses there will probably hurt a bit.

Although I have no exact statistics at hand now, I can show this,
which applies to modern ordinary Japanese text

Frequently used characters | Coverage of Text
---------------------------+-----------------
100                        |  50 %
1000                       |  80 %
2000                       |  95 %
7000                       |  99 %
60000 (or more)            |  100 %

(All are approximate values.)

This table shows how many characters in modern ordinary
Japanese text, say newspaper, are occupied by top frequently
used characters.

The reason of the deviation is: There are a relatively small
number of frequently used characters, while there are a huge
number of rarely used ones, some of which are never noticed
nor written during one's life time. (This is not a joke.)

As indicated by the table, any caches, even if they are relatively
small in number, fairly contributes to the performance improvement.
On the other hand, the larger the number is, the less the cost
performance is.  This is just the right place to use caches.

I guess Chinese text shows a similar tendency.  So, if we know
the average number of Chinese characters a Chinese kid learns
until she/he graduates from high school, we could derive the
resonable size of caches from it.

Furthermore, as a nature of CJK characters, glyph metrics are
relatively uniform in a font family (no kerning nor legature,
perhaps no composite glyph), this could be used for optimization.
In fact, lazy rendering sometimes has sufficient quality for
display and print, and it is actually used.

So, although the number of characters we have to cover for CJK
is incredibly vast, it would not matter in performance if we
have a well-designed cache management.

Regards,
- Kazunobu Kuriyama





reply via email to

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