colorMap := sourceForm depth ~= destForm depth

ifTrue: [ self cachedFontColormapFrom: sourceForm depth to: destForm depth ].

So if colorMap is set to nil for black text in install... method, it works fine for the first string displayed.

However, since the StrikeFonts have depth 16, and display depth is 32, in subsequent calls to displayString:... (without intermittent installs), colorMap will be the cached colorMap, and the second pass done no matter what.

This happens in MultiDisplayScanner when a stopCondition has been met as part of a string, f.ex. a tab.

The easiest solution I could find was simply resetting colorMap to secondPassMap at the end of displayString:... regardless of whether it's nil or not.

Attached is the smallish patch (removing the preference, and including the two changes), to be installed after EnhancedStrikeFonts-Pharo.4.cs; with that and the latest VM, I think we can safely enjoy single-pass rendering of black text without experiencing visual artifacts (well, in the cases I could find at least)

Cheers,

Henry

PS. if we want Pharo to look good on display depths < 32, we should probably look into AlphaInfiniteForms, and an alternate draw method for the drop shadow while dragging :) Try f.ex. evaluating Display setExtent: Display extent depth: 16

On Aug 21, 2009, at 11:41 49AM, Henrik Johansen wrote:

On Aug 21, 2009, at 2:10 03AM, John M McIntosh wrote:

I've posted a macintosh carbon VM 4.2.1Beta1U to the usual places
found via

... BitBlt fixes to enable beautiful fonts via Squeak on the macintosh...

Great! :D

Wasn't one of these fixes to make the "properAlphaForBlackText" setting unnecessary, or do I remember the discussion incorrectly?

Setting it to false, I get black text rendering like in the noProperAlpha.png.

The second pass seem to still run on black text, but with an improper colorMap, f.ex. you get coloured tints on your bolded fonts depending on what other colormaps have been used.

After making sure to nil the colorMap in installStrikeFont, I get black font rendering like in nilledColormap.png. Seems to me there's a bug in fonts used in MultiNewParagraph when lines start with a tab, but I can't figure out how to correct it... Juan? ;)

Cheers,

Henry

<noProperBlackAlpha.png><nilledColormap.png>
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project