Maybe for Etoys, too? I saw a speedup from 8026 to 7558 with about 10 windows open. What do others think ? Karl
-------- Original Message -------- Subject: [squeak-dev] Fwd: A little font rendering speedup Date: Sun, 19 Apr 2009 16:36:19 +0300 From: Igor Stasenko siguctua@gmail.com Reply-To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org To: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org, Pharo Development Pharo-project@lists.gforge.inria.fr
I put this on mantis, since i'm sure this applies to squeak3.10 and Pharo both.
http://bugs.squeak.org/view.php?id=7338
---------- Forwarded message ---------- From: Igor Stasenkosiguctua@gmail.com Date: 2009/4/19 Subject: A little font rendering speedup To: Pharo DevelopmentPharo-project@lists.gforge.inria.fr
This is an image-side change, which makes a primitiveDisplayString to not fail because StrikeFontSet returns nil for (font characterToGlyphMap).
Since the code, which using fast primitive looks like following:
self primDisplayString: aString from: startIndex to: stopIndex map: font characterToGlyphMap xTable: font xTable kern: kernDelta
I thought, why one would return nil in ( font characterToGlyphMap ). Since #xTable in StrikeFontSet implemented as following:
xTable "Answer an Array of the left x-coordinate of characters in glyphs."
^ (fontArray at: 1) xTable.
i think it is safe to do similar in characterToGlyphMap , this allows the primitive to work w/o failure, because otherwise, if you look at implementation of
primDisplayString: aString from: startIndex to: stopIndex map: glyphMap xTable: xTable kern: kernDelta
in fallback code it does same thing again (and ignoring glyphMap at all, btw).
To bench a difference, leave a couple of windows with text in world and then do:
[10 timesRepeat: [World fullDrawOn: World assuredCanvas] ] timeToRun
before change:
645
after change:
545