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

[Juan Vuletich]

Juan Vuletich wrote:
>
> 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.

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.

>
> 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?

Cheers,
Juan Vuletich