Looking at the latest FreeType, glyphs are cached (as forms) for each real
font looked up by a LogicalFont. Two different instances of LogicalFont that
happen to match actually has a second instance of real font.
Aside from that, the glyph cache contains entries (for a real font instance)
for any used character/sub-pixel-position/colour combination.
The creation of the cached glyph forms is quite computationally expensive
(as written in Squeak).
So, from a logical font, asking for its real font will (lazily) (at present)
load a new instance of FreeTypeFont, asking for a glyph (character) at a
particular sub-pixel position and colour will look up in the cache and, if
not present, create the form for it.
Given kerning etc, up to 64 sub-pixel positions may be involved for each
glyph. Currently, if the cache size limit (bytes of all glyph forms in the
cache) is hit the cache resets totally and subsequent requests will
regenerate the needed glyphs.
Upping the FreeType glyph cache limit helps though the fact that two
different instances of a LogicalFont (with the same parameters) will create
a new real FreeTypeFont, the cache tends to churn.
Given the multiple potential subpixel positions it is impractical to
pre-cache all the glyphs for a font, hence there is a perfomance hit on
first use of a glyph at a particular sub-pixel/colour point.
Moving the low-level glyph rendering loops into a plugin will help the
performance immensely.
Sorry, there is no "briefly" :-)
Regards, Gary.
----- Original Message -----
From: "Stéphane Ducasse" <[EMAIL PROTECTED]>
To: "Pharo Development" <[email protected]>
Sent: Wednesday, November 05, 2008 4:57 PM
Subject: Re: [Pharo-project] FreeType
I do not know anything about fonts
can you explain the cache mechanism for the font rendering?
briefly?
Stef
On Nov 5, 2008, at 4:20 PM, Gary Chambers wrote:
Hi all.
Using the latest FreeType (admittedly on a 3.9 image, though probably
generally applicable) we are noticing quite a lot of cache thrash,
meaning that the low-level glyph rendering is happening quite often.
Really noticeable on slow machines (our deployment target has 800MHz
processors).
Was wondering if it might me a good idea to move the cached form
rendering into a plugin (lots of bit manipulation in Squeak code loops)?
We've stabilised thing for the moment by hanging onto the LogicalFonts
used and modifying the real font lookup to reuse existing matches and
switching to CRT mode (3 times quicker). First use of glyphs at varying
subpixel positions miss the cache though.
Regards, Gary.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
