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?
Cheers, Juan Vuletich