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

[Juan Vuletich]

Juan Vuletich wrote:
>
> 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.
Done. You can see how well this works by going to 
http://www.jvuletich.org/Cuis/ and downloading the new Cuis #0204.
See how well it does subpixel AA with black and colored text. Change 
display depth, and see how it adapts to lower display depths. Also play 
with preferences #subpixelRenderText and #subpixelRenderColorText. All 
this is done with just one 16bpp glyph for each char/font/size! No extra 
caches. Just standard rules, colormaps, and thought.

Cheers,
Juan Vuletich