Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0007338 [Squeak] Graphics feature always 04-19-09 13:33 09-04-13 00:10
Reporter sig View Status public  
Assigned To tim
Priority normal Resolution duplicate  
Status closed   Product Version 3.10
Summary 0007338: A little font rendering speedup
Description This is an image-side change, which makes a primitiveDisplayString to
not fail because StrikeFontSet returns nil for (font

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:

       "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:


after change:

Additional Information
Attached Files [^] (554 bytes) 04-19-09 13:33

- Relationships

SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

duplicate of 0001781closed tim BitBlt>>primDisplayString: is failing often 
related to 0001650closed tim [BUG] CharacterScanner primitive is broken; char scanning generally in a mess 

- Notes
(0013085 - 1054 - 1251 - 1251 - 1251 - 1251 - 1251)
Damien Cassou
04-20-09 08:21

From Igor:
A more deeper analysis shows, that it looks like things around
characterToGlyphMap is either incomplete, or over-engineered.

By looking through all characterToGlyphMap uses, most methods simply
assigns nil to it.
The only method which would assign something different is

in [ characterToGlyphMap := self isoToSqueakMap ]

but what a surprise! it implemented as following:


IMO character to glyph mapping for strike fonts is redundant, because
you can simply remap the xTable to achieve same effect.

Also, since Pharo fully supports FreeType, doesn't it makes a HostFont
a candidate to wipe out?
If so, then i would really recomment to ignore characterToGlyphMap for
displaying ByteString(s) and use single class var which holds an
identity mapping for ascii chars.
This is, of course just to make a primitiveDisplayString happy. A more
aggressive way would be to rewrite this primitive and remove the
characterToGlyphMap argument from use.
(0013086 - 139 - 139 - 139 - 139 - 139 - 139)
04-21-09 15:17

I forgot to mention, that there is no code, which generating a mapping different than identity mapping i.e. ascii char code == array index
(0014442 - 8 - 8 - 8 - 8 - 8 - 8)
09-04-13 00:10

See 1781

- Issue History
Date Modified Username Field Change
04-19-09 13:33 sig New Issue
04-19-09 13:33 sig Status new => assigned
04-19-09 13:33 sig Assigned To  => andreas
04-19-09 13:33 sig File Added:
04-20-09 08:21 Damien Cassou Note Added: 0013085
04-21-09 15:17 sig Note Added: 0013086
07-22-13 02:52 tim Relationship added related to 0001781
07-22-13 02:53 tim Relationship added related to 0001650
07-22-13 02:53 tim Assigned To andreas => tim
09-04-13 00:09 tim Relationship replaced duplicate of 0001781
09-04-13 00:10 tim Status assigned => closed
09-04-13 00:10 tim Note Added: 0014442
09-04-13 00:10 tim Resolution open => duplicate
09-04-13 00:10 tim Fixed in Version  => 4.4

Mantis 1.0.8[^]
Copyright © 2000 - 2007 Mantis Group
61 total queries executed.
41 unique queries executed.
Powered by Mantis Bugtracker