Thanks. I'll do some further benchmarks once in the office.
Regards, Gary.
----- Original Message -----
From: "Andrew Tween" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Sunday, November 09, 2008 6:21 PM
Subject: [Pharo-project] Re: FreeType
Hi Gary,
"Gary Chambers" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]
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
[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
