Mantis Bugtracker
  

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0001781 [Squeak] Graphics feature always 09-11-05 06:48 09-04-13 00:07
Reporter Eddie Cottongim View Status public  
Assigned To tim
Priority normal Resolution fixed  
Status closed   Product Version 3.9
Summary 0001781: BitBlt>>primDisplayString: is failing often
Description The primitive is failing in at least two instances.

The most important one is that it will always fail when trying to print a StrikeFontSet (which is very often). This is because StrikeFontSet has a nil glyphMap. It costs about 30-50% of printing performance.

The other is that the prim fails when called with a nil string. This is just a nuisance, but perhaps it should be caught further upstream.
Additional Information This patch tries to fix the problem. It seems to work and provide a speedup. However, it is hardwired to use the latin1 encoding because I couldn't figure out the class well enough to understand what to do. Also I have no idea if a glyphMap is even appropriate for a StrikeFontSet. Oh for class comments. Anyway, maybe it will help someone start, because I won't have time to completely polish this.

Here is a semi useful benchmark. I got 1071 before, 772 after.

text := '012345678901234567890123456789'.
font := TextStyle default fontOfSize: 12.
width _ font widthOfStringOrText: text.
bb := (Form extent: width @ 30) getCanvas privatePort.
bb combinationRule: Form paint.

font installOn: bb foregroundColor: Color black backgroundColor: Color white.
    
Time millisecondsToRun:[
10000 timesRepeat: [
destPoint := font displayString: text on: bb from: 1 to: 30 at: 0@0 kern: 1.
].].
Attached Files  FontExperiment.2.cs [^] (1,007 bytes) 09-11-05 06:48

- Relationships
related to 0001650closed tim [BUG] CharacterScanner primitive is broken; char scanning generally in a mess 
has duplicate 0007338closed tim A little font rendering speedup 

- Notes
(0002640 - 63 - 63 - 63 - 63 - 63 - 63)
Eddie Cottongim
09-11-05 20:45

Correction, where i said nil string, I meant empty string ('').
 
(0002964 - 115 - 115 - 115 - 115 - 115 - 115)
andreas
10-25-05 07:43

I have changed this to a feature request. Primitives failing isn't a bug per se - it's perfectly expected behavior.
 
(0002973 - 165 - 165 - 165 - 165 - 165 - 165)
Eddie Cottongim
10-25-05 16:34

Fair enough. I think I had really meant it as a bug against StrikeFontSet which wasn't using BitBlt in such a way that it could ever succeed. Its not BitBlt's fault.
 
(0003258 - 365 - 411 - 411 - 411 - 411 - 411)
Eddie Cottongim
12-10-05 07:33

Update on this:

The attached code (FontExperiment2) no longer works as of 6705. It hangs the image.

The "issue" is still there though, and text scrolling suffers noticably for it.

I'm not sure what to do about this. Fonts need a major re-wacking, but I don't have time for that. I probably have time for a band-aid, but there are too many of those already.
 
(0014403 - 338 - 338 - 338 - 338 - 338 - 338)
tim
07-22-13 02:08

Eddie seems to be correct, so far as I can tell. Why doesn't StrikeFontSet return a plain characterToGlyphMap just like StrikeFont? After all, when in the ST backup code there is a reference to the font's height or glyphs then the height or glyphs of the first font in the font array is returned. Why not the relevant characterToGlyphMap?
 
(0014440 - 1334 - 1450 - 1450 - 1450 - 1450 - 1450)
tim
09-03-13 23:54

As it happens, StrikeFontSets appear to be pretty much unused in the 4.5 era image, so in a way this is a moot point. However, after digging into the insanity that is font handling I concluded that characterToGlyphMap should return the characterToGlyphMap of the font set's first contained font. This echoes the implementations of #ascent etc and furthermore the *only* usage outside StrikeFont internal methods is by primDisplayString:from:to:map:xTable: in the prim failure recovery code. By the time this is used we know that the string is a byteString and thus by following the workings of StrikeFontSet we can see that the first font must be the one used.

On a 3.4GHz/core i7 quad core iMac this improves the results of a slightly altered benchmark from 2436 to 1733, i.e. about 30%. Useful sort of improvement for slower machines.

The replacement test code is -
text := '012345678901234567890123456789'.
font := StrikeFontSet newFontArray: (TextStyle default fontArray).
width _ font widthOfStringOrText: text.
bb := (Form extent: width @ 30) getCanvas privatePort.
bb combinationRule: Form paint.

font installOn: bb foregroundColor: Color black backgroundColor: Color white.
    
Time millisecondsToRun:[
100000 timesRepeat: [
destPoint := font displayString: text on: bb from: 1 to: 30 at: 0@0 kern: 1.
].].
 
(0014441 - 558 - 612 - 612 - 612 - 612 - 612)
tim
09-04-13 00:07

(Actually fixed for 4.5 but you can't say that.)

Fixed the problem with a sensible implementation of characterToGlyphMap for StrikeFontSet; though they're not apparently used a great deal in current images. It makes a worthwhile 30%-ish improvement in rendering speed.

I'd like to thank the kind people that caused such a complicated mess of font related code to get into the image; without this sort of issue I'd never have had the chance to burn so many braincells in a single sitting.

See -
Graphics tpr.22
Multilingual tpr.167
TrueType tpr.26
 

- Issue History
Date Modified Username Field Change
09-11-05 06:48 Eddie Cottongim New Issue
09-11-05 06:48 Eddie Cottongim File Added: FontExperiment.2.cs
09-11-05 20:40 Eddie Cottongim Issue Monitored: Eddie Cottongim
09-11-05 20:45 Eddie Cottongim Note Added: 0002640
10-25-05 05:36 andreas Category Morphic => Graphics
10-25-05 07:43 andreas Note Added: 0002964
10-25-05 07:43 andreas Severity minor => feature
10-25-05 16:34 Eddie Cottongim Note Added: 0002973
12-10-05 07:33 Eddie Cottongim Note Added: 0003258
07-22-13 02:05 tim Relationship added related to 0001650
07-22-13 02:08 tim Note Added: 0014403
07-22-13 02:12 tim Status new => assigned
07-22-13 02:12 tim Assigned To  => tim
07-22-13 02:52 tim Relationship added related to 0007338
09-03-13 23:54 tim Note Added: 0014440
09-04-13 00:07 tim Status assigned => resolved
09-04-13 00:07 tim Fixed in Version  => 4.4
09-04-13 00:07 tim Resolution open => fixed
09-04-13 00:07 tim Note Added: 0014441
09-04-13 00:07 tim Status resolved => closed
09-04-13 00:09 tim Relationship replaced has duplicate 0007338


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