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

[Andrew Tween]

Hi ,

The way the new bitBlt mode works is as follows.

 

The source bitmap is treated as a mask that contains the alpha values for each sub-pixel ( Red, Green, and Blue) individually.

There are 8 bits per sub-pixel, i.e. 24 bits per pixel.

 

The text foreground color is specified separately.

 

The alpha blending then takes place individually for each red, green & blue sub-pixel.

 

The formula is this...

 

 dst.A =  colorAlpha + (1 - colorAlpha) * dst.A
      dst.R = color.R * mask.R * colorAlpha + (1 - (mask.R * colorAlpha)) * dst.R
      dst.G = color.G * mask.G * colorAlpha + (1 - (mask.G* colorAlpha)) * dst.G
      dst.B = color.B * mask.B * colorAlpha + (1 - (mask.B* colorAlpha)) * dst.B

(color and colorAlpha are the text color, and its translucency, and apply to all pixels)

 

 

Using this formula, when black text is rendered on a white background, some of the pixels become 'coloured'. Typically, this results in red fringes on the left edges if a glyph, and blue fringes on the right. It is this colour fringing that 'fools the eye' into seeing sharper text on an LCD screen. 

 

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 :)

 

All the code I have written for the bitBlt mode and Freetype is MIT licensed.

 

(In addition, the new bitBlt mode applies gamma correction and deals with destination depths of less than 32, but that is not really relevant to this discussion)

 

Cheers,

Andy

 

.


 
> Date: Wed, 20 May 2009 13:32:11 -0700
> From: andreas.raab at gmx.de
> To: vm-dev at lists.squeakfoundation.org
> 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

_________________________________________________________________
Beyond Hotmail — see what else you can do with Windows Live.
http://clk.atdmt.com/UKM/go/134665375/direct/01/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090520/b1a2a5a8/attachment-0001.htm