[Pharo-project] 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 <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
Hi John, On Fri, Aug 21, 2009 at 2:10 AM, John M McIntosh<johnmci@smalltalkconsulting.com> wrote:
I've posted a macintosh carbon VM 4.2.1Beta1U to the usual places found via
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
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
------------------------------------------------------------------------------ _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Damien Cassou -
Gary Chambers -
Henrik Johansen -
John M McIntosh