Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

> Thanks, Damien!
>
> Note, on Mac, the VM "Squeak 4.1.1beta2U" does not contain the new  
> BitBlt plugin and hence the fonts are rendered without subpixel  
> antialiasing. To enable this, drop the attached file (this is from  
> the prototype one-click-image that Marcus produced some time ago) in  
> the Resources folder in the VM app.
>
> John, could this be included by default in the VMs you ship?
>
> Cheers,
> Adrian

> I did a quick smoke test on a 64-bit Linux. I get a working VM but also
> some compiler warnings associated with the new changes. I can't say if
> there are functional issues, but I note that warnings about cast from
> pointer to integer are usually associated with VM crashes on a 64-bit
> platform, so this might be a problem.
>
> - Dave
>
> Output from a compile on Linux 64 bit:
>
> gcc -g -O2 -DLSB_FIRST=1  -DHAVE_CONFIG_H  -DSQUEAK_BUILTIN_PLUGIN -I/home/lewis/squeak/VMM/build32 -I/home/lewis/squeak/VMM/platforms/unix/vm -I/home/lewis/squeak/VMM/platforms/Cross/vm -I/home/lewis/squeak/VMM/src/vm    -c -o BitBltPlugin.o /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘copyLoop’:
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:1556: warning: cast to pointer from integer of different size
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘copyLoopNoSource’:
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:1728: warning: cast to pointer from integer of different size
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘copyLoopPixMap’:
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:1840: warning: cast to pointer from integer of different size
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘loadSurfacePlugin’:
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3064: warning: assignment makes integer from pointer without a cast
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3065: warning: assignment makes integer from pointer without a cast
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3066: warning: assignment makes integer from pointer without a cast
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘lockSurfaces’:
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3123: warning: cast to pointer from integer of different size
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3159: warning: cast to pointer from integer of different size
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘mergewith’:
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3202: warning: cast to pointer from integer of different size
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘partitionedRgbComponentAlphadestnBitsnPartitions’:
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:3595: warning: left shift count >= width of type
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘primitiveWarpBits’:
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:4304: warning: cast to pointer from integer of different size
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:4335: warning: cast to pointer from integer of different size
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘queryDestSurface’:
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:4411: warning: cast to pointer from integer of different size
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘querySourceSurface’:
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:4429: warning: cast to pointer from integer of different size
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘rgbComponentAlphawith’:
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5046: warning: left shift count >= width of type
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘unlockSurfaces’:
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5730: warning: cast to pointer from integer of different size
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘warpBits’:
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5788: warning: cast to pointer from integer of different size
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5819: warning: cast to pointer from integer of different size
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c: In function ‘warpLoop’:
> /home/lewis/squeak/VMM/src/vm/intplugins/BitBltPlugin/BitBltPlugin.c:5931: warning: cast to pointer from integer of different size
>
>

> David T. Lewis wrote:
> > I don't really know the background on this, but assuming that this is
> > an incremental change to BitBltSimulation, and that the changes are
> > MIT licensed, and also that they are in need of a home, then adding them
> > to the VMMaker package would be the right thing to do.
> >
> > Andreas should have veto rights, as I believe that he is the author
> > of BitBltSimulation.
>
> The original author of BBSim is of course Dan. My only question about
> these changes is that I'm not sure what they're actually doing - it
> looks like rgbMul:with: except that it's been unrolled for various
> cases. Does anyone know what these changes are supposed to be doing,
> where they are used, and why rgbMul:with: is not sufficient?

> On Tue, 2009-05-19 at 23:29 -0700, Andreas Raab wrote:
>> David T. Lewis wrote:
>>> I don't really know the background on this, but assuming that this is
>>> an incremental change to BitBltSimulation, and that the changes are
>>> MIT licensed, and also that they are in need of a home, then adding them
>>> to the VMMaker package would be the right thing to do.
>>>
>>> Andreas should have veto rights, as I believe that he is the author
>>> of BitBltSimulation.
>> The original author of BBSim is of course Dan. My only question about
>> these changes is that I'm not sure what they're actually doing - it
>> looks like rgbMul:with: except that it's been unrolled for various
>> cases. Does anyone know what these changes are supposed to be doing,
>> where they are used, and why rgbMul:with: is not sufficient?
>
> The changes are Andy Tweens extensions for subpixel anti-aliassing for
> freetype. I'm not sure why rgbMul:with: isn't sufficient.

> Bryce Kampjes wrote:
>> On Tue, 2009-05-19 at 23:29 -0700, Andreas Raab wrote:
>>> David T. Lewis wrote:
>>>> I don't really know the background on this, but assuming that  
>>>> this is
>>>> an incremental change to BitBltSimulation, and that the changes are
>>>> MIT licensed, and also that they are in need of a home, then  
>>>> adding them
>>>> to the VMMaker package would be the right thing to do.
>>>>
>>>> Andreas should have veto rights, as I believe that he is the author
>>>> of BitBltSimulation.
>>> The original author of BBSim is of course Dan. My only question  
>>> about these changes is that I'm not sure what they're actually  
>>> doing - it looks like rgbMul:with: except that it's been unrolled  
>>> for various cases. Does anyone know what these changes are  
>>> supposed to be doing, where they are used, and why rgbMul:with: is  
>>> not sufficient?
>> The changes are Andy Tweens extensions for subpixel anti-aliassing  
>> for
>> freetype. I'm not sure why rgbMul:with: isn't sufficient.
>
> Do you know if he's around to shed some light on it?
>
> Cheers,
>  - Andreas

> On May 20, 2009, at 22:32 , Andreas Raab wrote:
>
>> Bryce Kampjes wrote:
>>> On Tue, 2009-05-19 at 23:29 -0700, Andreas Raab wrote:
>>>> David T. Lewis wrote:
>>>>> I don't really know the background on this, but assuming that this is
>>>>> an incremental change to BitBltSimulation, and that the changes are
>>>>> MIT licensed, and also that they are in need of a home, then adding
>>>>> them
>>>>> to the VMMaker package would be the right thing to do.
>>>>>
>>>>> Andreas should have veto rights, as I believe that he is the author
>>>>> of BitBltSimulation.
>>>> The original author of BBSim is of course Dan. My only question
>>>> about these changes is that I'm not sure what they're actually doing
>>>> - it looks like rgbMul:with: except that it's been unrolled for
>>>> various cases. Does anyone know what these changes are supposed to
>>>> be doing, where they are used, and why rgbMul:with: is not sufficient?
>>> The changes are Andy Tweens extensions for subpixel anti-aliassing for
>>> freetype. I'm not sure why rgbMul:with: isn't sufficient.
>>
>> Do you know if he's around to shed some light on it?
>>
>> Cheers,
>>  - Andreas
>

>
> On 20.05.2009, at 14:19, Andreas Raab wrote:
>
>> Adrian Lienhard wrote:
>>> I've sent Andrew a mail to his hotmail.com account this morning  
>>> but haven't received a reply so far.
>>
>> Thanks. BTW, the reason why I'm asking is that I've been using the  
>> Truetype stuff in the past and I don't recall the need for bitblt  
>> mods. Is there a possibility that once upon a time there was a need  
>> for this and now there no longer is? The date on the changeset is  
>> 2004...
>
> IIRC this is for sub-pixel font rendering support and was never  
> officially integrated. With current bitblt you do nit git sub-pixel  
> AA.

> Date: Wed, 20 May 2009 13:32:11 -0700
> From: [hidden email]
> To: [hidden email]
> Subject: Re: [Vm-dev] Fwd: [Pharo-project] New Pharo based on core 10309 with antialiased fonts
>
>
> Bryce Kampjes wrote:
> > On Tue, 2009-05-19 at 23:29 -0700, Andreas Raab wrote:
> >> David T. Lewis wrote:
> >>> I don't really know the background on this, but assuming that this is
> >>> an incremental change to BitBltSimulation, and that the changes are
> >>> MIT licensed, and also that they are in need of a home, then adding them
> >>> to the VMMaker package would be the right thing to do.
> >>>
> >>> Andreas should have veto rights, as I believe that he is the author
> >>> of BitBltSimulation.
> >> The original author of BBSim is of course Dan. My only question about
> >> these changes is that I'm not sure what they're actually doing - it
> >> looks like rgbMul:with: except that it's been unrolled for various
> >> cases. Does anyone know what these changes are supposed to be doing,
> >> where they are used, and why rgbMul:with: is not sufficient?
> >
> > The changes are Andy Tweens extensions for subpixel anti-aliassing for
> > freetype. I'm not sure why rgbMul:with: isn't sufficient.
>
> Do you know if he's around to shed some light on it?
>
> Cheers,
> - Andreas

> On 20.05.2009, at 14:33, Bert Freudenberg wrote:
>> On 20.05.2009, at 14:19, Andreas Raab wrote:
>>> Adrian Lienhard wrote:
>>>> I've sent Andrew a mail to his hotmail.com account this morning but
>>>> haven't received a reply so far.
>>>
>>> Thanks. BTW, the reason why I'm asking is that I've been using the
>>> Truetype stuff in the past and I don't recall the need for bitblt
>>> mods. Is there a possibility that once upon a time there was a need
>>> for this and now there no longer is? The date on the changeset is
>>> 2004...
>>
>> IIRC this is for sub-pixel font rendering support and was never
>> officially integrated. With current bitblt you do nit git sub-pixel AA.
>
>
> Err ... that should have been "you do not get" of course.

> ...
>  
> It is possible to replicate this effect by storing these 'coloured'
> glyphs, and rendering them using the existing bitBlt rules, and, for
> black text on a white background, it will give the correct result.
>  
> But, when these same glyphs are rendered to a black background (i.e.
> black text on a black background), the colour fringes in the resulting
> output are still visible. This is of course wrong; black text on a
> black background should result in a completely black result with no
> glyphs visible at all.
>  
> It would be possible to use the existing bitBlt modes if the
> background colour was known in advance. In this case glyphs could be
> created and cached for each foreground/background combination.
> But, this is usually not the case. The background might be a gradiant
> , or an image, or some other pattern.
>  
> Furthermore, the text colour may not be black - it can be any colour
> with any level of translucency.
>  
> I believe that the existing bitBlt rules are insufficient to cover all
> these circumstances, but I am happy to be proved wrong :)

>
> Hi Folks,
>
> Andrew Tween wrote:
>> ...
>>  
>> It is possible to replicate this effect by storing these 'coloured'
>> glyphs, and rendering them using the existing bitBlt rules, and, for
>> black text on a white background, it will give the correct result.
>>  
>> But, when these same glyphs are rendered to a black background (i.e.
>> black text on a black background), the colour fringes in the
>> resulting output are still visible. This is of course wrong; black
>> text on a black background should result in a completely black result
>> with no glyphs visible at all.
>>  
>> It would be possible to use the existing bitBlt modes if the
>> background colour was known in advance. In this case glyphs could be
>> created and cached for each foreground/background combination.
>> But, this is usually not the case. The background might be a gradiant
>> , or an image, or some other pattern.
>>  
>> Furthermore, the text colour may not be black - it can be any colour
>> with any level of translucency.
>>  
>> I believe that the existing bitBlt rules are insufficient to cover
>> all these circumstances, but I am happy to be proved wrong :)
>
> Well, not all these circumstances, but all those with black text. You
> can see in the latest Cuis that rgbMul is enough for correct subpixel
> rendering of black text over any background. And yes, black on black
> shows all black. In fact, rgbMul is the same formula than rule 41 if
> text color is black (0;0;0).
>
> In Cuis I disable subpixel rendering for colored text. I found that
> for colored text, the difference between doing or not subpixel
> rendering is much less visible.
>
> As I write this, I realize that it could be possible to do subpixel
> rendering with smarter colormaps... I guess I'll play a bit with this
> idea.

>
> BTW, I tried to use rule 41 in Cuis, but as r, g and b are alpha
> values (0 meaning transparent, 255 meaning opaque), the glyph form can
> not be the same as used for other rules (such as rgbMul and Paint). As
> I have a single glyph for each char/font/size, and I need to use
> different rules and colormaps to adapt to various display depths and
> text colors, I could not use rule 41. It would have made more sense to
> me to store transparency values (0 meaning opaque, 255 meaning
> transparent).
>
> Finally, I wonder, what do you guys use for text rendering for your
> Squeak programming? Are you happy with just full pixel AA on LCD screens?

>
>> In Cuis I disable subpixel rendering for colored text. I found that
>> for colored text, the difference between doing or not subpixel
>> rendering is much less visible.
>
> Personally, I find there is very little difference between subpixel AA
> or not even with black text. What *really* makes the difference for
> font rendering is grid-fitting; which is why both native fonts (TTF
> hinting) as well as Freetype (excellent auto-hinter) look much better
> than Squeak fonts by default.
>
> Cheers,
>   - Andreas

>
> Juan Vuletich wrote:
>>
>> Andrew Tween wrote:
>>> ...
>>>  
>>> It is possible to replicate this effect by storing these 'coloured'
>>> glyphs, and rendering them using the existing bitBlt rules, and, for
>>> black text on a white background, it will give the correct result.
>>>  
>>> But, when these same glyphs are rendered to a black background (i.e.
>>> black text on a black background), the colour fringes in the
>>> resulting output are still visible. This is of course wrong; black
>>> text on a black background should result in a completely black
>>> result with no glyphs visible at all.
>>>  
>>> It would be possible to use the existing bitBlt modes if the
>>> background colour was known in advance. In this case glyphs could be
>>> created and cached for each foreground/background combination.
>>> But, this is usually not the case. The background might be a
>>> gradiant , or an image, or some other pattern.
>>>  
>>> Furthermore, the text colour may not be black - it can be any colour
>>> with any level of translucency.
>>>  
>>> I believe that the existing bitBlt rules are insufficient to cover
>>> all these circumstances, but I am happy to be proved wrong :)
>> ...
>
> I was not clear here. I meant that it came to me that it is possible
> to do _colored_ subpixel rendered text over any background with
> smarter colormaps. I played a bit with it. It can be done. But it
> requires two BitBlts, one after the other. The glyph is "natural",
> i.e. black on white with subpixel AA, like a screen capture from
> redered text. The first pass does rgbMul. This is the first half of AA
> at each subpixel. It is also all what's needed for black text. If we
> have colored text, we do a second path, using a colormap done by
> multiplying each component of the intended text color by (1.0 - each
> component of the index colors). This second pass does rgbAdd. Both
> passes do the full sub pixel AA.
>
> In the end, I guess we can say that the existing rules are enough to
> cover all these circumstances. The only problem is requiring 2 BitBlts
> is some cases.