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.
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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" <stephane.ducasse@inria.fr> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Having said all that, FreeType is a must. The font quality is awesome. ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: "Pharo Development" <pharo-project@lists.gforge.inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Changing the cache management policy and enhancing the mapping of logical to real fonts seem like relatively low hanging fruit or am I missing something? -david On Wed, Nov 5, 2008 at 11:19 AM, Gary Chambers <gazzaguru2@btinternet.com>wrote: [snip]
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.
Hi Gary, "Gary Chambers" <gazzaguru2@btinternet.com> wrote in message news:859BE9D591B44E858830F5D4B74DFF26@GuruVista...
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)?
The real killer is FreeTypeSubPixelAntiAliasedGlyphRenderer>>filter: Moving it into a plugin would certainly speed things up. I've had a quick look to see what can be done to speed it up. By hardcoding the filter parameters, and replacing floating point arithmetic with integer arithmetic, I have doubled its speed. (Attached as FreeTypeSubPixelAntiAliasedGlyphRenderer-filter.st)
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.
Clearly I need to do some work on this. Much of the current design is based on assumptions which, for a Pharo one-click distribution, are no longer valid. e.g. 1.The modified BitBlt plugin might not be present. 2.The FT2Plugin might not be present. 3.The display depth might be 16bit or 8 bit (or 4bit !? ) 4.The current world might be MVC The current design is also based on plans I had for extra features (font substitution, glyph substitution, hinting mode & kerning on a per-font basis rather than as global settings). The current code is arguably over-engineered, with obvious signs of YAGNI. I'll try to simplify it. As you have discovered, the sixty four possible sub-pixel positions reduces the chances of a cache hit and slows things down. Sixty four is the maximum resolution that FreeType supports. Using a lower resolution will speed things up, and the difference in rendering quality may not be noticable. (IIRC Sophie used a much lower resolution - 2 or 3 sub-pixel positions). To change the resolution, modify FreeTypeFont>>glyphOf:destDepth:colorValue:subpixelPosition: so that this line... ifTrue: [((sub asInteger max: 0) min: 63) "bitAnd: 2r1111000"] reads... ifTrue: [((sub asInteger max: 0) min: 63) bitAnd: 2r1111000] This will reduce the 64 possible positions to 8 (use 2r1111100 for 16 positions; 2r1111110 for 32 positions, 2r11110000 for 4 positions, etc.) n.b. Reducing the number of sub-pixel positions will speed up both the CRT mode and the LCD mode. Cheers, Andy
Regards, Gary.
Thanks. I'll do some further benchmarks once in the office. Regards, Gary. ----- Original Message ----- From: "Andrew Tween" <amtween@hotmail.com> To: <pharo-project@lists.gforge.inria.fr> Sent: Sunday, November 09, 2008 6:21 PM Subject: [Pharo-project] Re: FreeType
Hi Gary,
"Gary Chambers" <gazzaguru2@btinternet.com> wrote in message news:859BE9D591B44E858830F5D4B74DFF26@GuruVista...
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)?
The real killer is FreeTypeSubPixelAntiAliasedGlyphRenderer>>filter: Moving it into a plugin would certainly speed things up.
I've had a quick look to see what can be done to speed it up. By hardcoding the filter parameters, and replacing floating point arithmetic with integer arithmetic, I have doubled its speed. (Attached as FreeTypeSubPixelAntiAliasedGlyphRenderer-filter.st)
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.
Clearly I need to do some work on this. Much of the current design is based on assumptions which, for a Pharo one-click distribution, are no longer valid. e.g.
1.The modified BitBlt plugin might not be present. 2.The FT2Plugin might not be present. 3.The display depth might be 16bit or 8 bit (or 4bit !? ) 4.The current world might be MVC
The current design is also based on plans I had for extra features (font substitution, glyph substitution, hinting mode & kerning on a per-font basis rather than as global settings). The current code is arguably over-engineered, with obvious signs of YAGNI. I'll try to simplify it.
As you have discovered, the sixty four possible sub-pixel positions reduces the chances of a cache hit and slows things down. Sixty four is the maximum resolution that FreeType supports. Using a lower resolution will speed things up, and the difference in rendering quality may not be noticable. (IIRC Sophie used a much lower resolution - 2 or 3 sub-pixel positions). To change the resolution, modify FreeTypeFont>>glyphOf:destDepth:colorValue:subpixelPosition: so that this line...
ifTrue: [((sub asInteger max: 0) min: 63) "bitAnd: 2r1111000"]
reads... ifTrue: [((sub asInteger max: 0) min: 63) bitAnd: 2r1111000]
This will reduce the 64 possible positions to 8 (use 2r1111100 for 16 positions; 2r1111110 for 32 positions, 2r11110000 for 4 positions, etc.)
n.b. Reducing the number of sub-pixel positions will speed up both the CRT mode and the LCD mode.
Cheers, Andy
Regards, Gary.
--------------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Andrew Tween -
David Pennell -
Gary Chambers -
Stéphane Ducasse