Funilly enough, I've recently done some fixups to improve appearance at lower
bit depths.
Drop shadow while dragging is annoying though, given it renders correctly when
not dragging!
Regards, Gary
----- Original Message -----
From: Henrik Johansen
To: [email protected]
Sent: Friday, August 21, 2009 4:40 PM
Subject: Re: [Pharo-project] Mac carbon VM 4.2.1Beta1U posted
Found the problem, I think.
In displayString: from: to: at: strikeFont: kern:
we have:
secondPassMap := colorMap.
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
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------------
Found the problem, I think.
In displayString: from: to: at: strikeFont: kern:
we have:
secondPassMap := colorMap.
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
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------------
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
