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