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