On Aug 7, 2009, at 8:22 12AM, Stéphane Ducasse wrote:
> Thanks thanks thanks. Henrik this is cool that we get such an
> analysis. Do you have an idea of the memory usage too :)
>
> Stef
>
> On Aug 6, 2009, at 4:24 PM, Henrik Johansen wrote:
Without a memory allocation profiler, anything becomes a(n educated,
at best) guess.
Mine would be the glyph cache lookup code, where 95% of the
"rendering" time is spent.
For _each_ character rendered a loopup is made in a 3-layer dictionary
to find the glyph:
1. By font
- hashed by font size, so if f.ex you're using 2 fonts of size9,
you're practically guaranteed collisions...
2. By character code.
- 99% of the time, this will be in ascii range, might be a good idea
to use a special class with array access for values 32-255, and a dict
lookup just for the rest
3 By color/subpixel-position...
- Character widths are also stored here. (but color/subpixel position
make up 98% of these lookups)
- Hashed by color value + subPixelPosition << 32, so you're always
doing LargeInteger comparisions for lookups. Yay.
- The color value calculation goes red << 24 + green << 16 + blue <<
8 + alpha, so does 4 LargeInt additions instead of 3 SmallInteger adds
and 1 LargeInt. Yay.
Also, every time a cached glyphs is accesed, it is pushed to top of a
LinkedList, the only thing I can see this LinkedList currently used
for, is easy access to all the CacheItem instances when removing them
all... The idea was probably to sometimes just remove the least used
ones, but that's currently not done, as far as I can see.
So in conclusion, the cache strategy in FreeType could benefit from a
major rethinking :)
Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
