Mac carbon VM 4.2.1Beta1U posted

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

http://www.smalltalkconsulting.com/squeak.html

If there are no immediate problems then people should consider using  
this VM for their one-click offerings and
ensuring this is the current default macintosh VM  on Squeak.org.  
Early adopters should email the list right away in
case of problems.

As a reminder the 4.x series of macintosh VM have clean 32bit address  
space support, IPV6, full UTF-8 for file names
and clipboard, Closure support when activated by the image, and BitBlt  
fixes to enable beautiful fonts via Squeak on the macintosh,
plus the VM plugins folder has all the latest plugins.

If you *must* run a 3.8.x flavor of VM (why?) then you should use the  
latest fixed version which is 3.8.21b1
3.8.20 & 3.8.19 both have flaws causing image save failures, and  
3.8.17 or earlier are not 32bit clean hence more probable to crash
  on you.

A warning about BitBltPlugin.bundle distributed as  
"BitBltPlugin.v1.0.0b1.FreeTypePlus.bundle.zip"
This was an override to provide some better font behaviour rendering  
that was done in early 2007.
If you have this on your computer in a Plugins folder or think you  
need it, beware it will override the NEW fixed bitblt and
you wonder why your fonts don't render correctly in the last font  
efforts for Squeak. Therefore you should delete all/any
copies of BitBltPlugin.bundle

Changes:

There are some fixes to enable this VM to run a 64bit based Image,  
this is still a 32bit VM btw, and now
the VM comes with a macintosh QuickLook plugin that renders the  
thumbnail out of newer eToys projects.
Plus it has the Aug fixes for rendering antialiased StrikeFonts.

Other fixes detailed below:

4.2.1b1 We update our VM to VMMaker-dtl.135
                        Fixes
                        Reference Mantis 7260: some Float comparison primitives don't  
handle Nan correctly
                        Enable VM to run 64 bit images as a 32 bit VM
                        Reference Mantis 5238: Integer bug on 64bit image/32bit VM
                        Reference Mantis 7376: Bug in BitBlt (rgbMul sets alpha to 0)
                        Reference Mantis 7377: VM Crashes when setting port on destroyed  
socket (Win32)
                        Reference Mantis 7384: GeniePlugin does not compile on closure-
enabled images

                        Added eToys suggestion for a read only resource directory when  
sandboxed.
                        Info.plist gets a UTI and the SqueakResourceDirectory path
                        Via Bert Freudenberg added QuickLook plugin for rendering eToys  
project image Thumbnail

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>   Twitter:  
squeaker68882
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================





_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi John,

On Fri, Aug 21, 2009 at 2:10 AM, John M
McIntosh<[hidden email]> wrote:
> I've posted a macintosh carbon VM 4.2.1Beta1U to the usual places found via
>
> http://www.smalltalkconsulting.com/squeak.html

thank you very much. I've updated the Pharo website to point to this new VM.


--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Found the problem, I think.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

----- Original Message -----

From: [hidden email]

To: [hidden email]

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
[hidden email]
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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

---

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hi Juan & all!
Having used StrikeFonts v6 for some while now, I have some more  
feedback:
- . are really hard to read on a 1920x1200 17inch display... I'm not  
sure if it's the size of the glyph in it self, but it really could at  
least use some more space up front, usually I can't distinguish it  
from the preceding character.
- It does not play well with the displayMultiString:on: from: to: at:  
kern: baselineY: - method used for WideStrings in general, ASCII  
characters are then rendered as black blocks.
Thing is, MultiDisplayScanner which is used in Pharo for TextEditors  
(well, most of them anyways, I haven't checked all) uses non-ascii  
characters as a stopCondition, thus any sequence in the string  
from:to: will always either be valid ASCII, or all unicode (for  
which ? is rendered correctly).
So a possible solution is to check if first character is ascii, if so  
it's safe to use the standard method (which renders it correctly).
Yet, it feels quite hackish to rely on the scanner dividing string  
into runs of ascii and non-ascii characters, (much faster though, as  
if the original method is used, a run of ascii-characters that happens  
to be part of a WideString,  will be rendered one character at a time).
It is however, a hack which will be quickly discovered if the pre-
conditions change :)

Would you be able to find some time to look into what it'd take to  
make the glyph-by-glyph rendering in misplayMultiString: work with the  
new StrikeFonts?
To the others:
- Would such a hack be acceptible for the moment?
        + Speeds up font rendering of strings with non-ascii characters (both  
FreeType and StrikeFonts)
        + Makes StrikeFonts v6 usable without further modifications
        - Is a hack dependent on the Scanner implementation.
        + Is easy to detect if preconditions change (basically, font  
rendering will fail :P)

The alternate which is not Scanner dependent, is iterating each  
character in the run instead of just checking first. It's slower, and  
StrikeFonts will still fail to render if displayMultiString: goes  
unfixed. Not to mention, if a Scanner is made that does not make sure  
runs are either ASCII or from an extended charset, the slow method of  
rendering a glyph at a time will be used anyways...

Cheers,
Henry

P.S: To the "We have FT fonts! Why care about StrikeFonts?"- replies.
Yes, I know that.
But:
        - Rendering is (no offense) slow.
        - Juans StrikeFonts code is good quality code of how it should be  
done. Increasing the ratio of such code compared to that which makes  
you go "Uuuuhh... " is one of the main reasons I got interested in  
Pharo, to make the Smalltalk experience for those determined on an OS-
licensed smalltalk comparable to that I have working in VW on a daily  
basis.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project