> If it's possible at all, it should be also possible to implement LCD
> optimized
> rendering directly in RGBA.
Are you absolutely sure that it is not simply *adding* the seperate alpha of
RGB used in the scanline, and that is the common alpha? You create the
separate alphas by stretching the geometry by a factor of 3 horizontally. So
calculating the common alpha should simply be "unstretching" the geometry,
which is done by simply adding the alpha values, no?
Of course, if you need to apply "weighting" to the different RGB alphas to
avoid color fringing, then it should be done after the common alpha is
calculated.
Err. I just realized it might not be that simple. I'm still thinking about
it... But it must have something to do with reversing the effects of
"stretching by 3"...
Well, basically it looks like averaging, but it's not that easy. Suppose we
don't have any AGG stuff and call WinAPI AlphaBlend() or something similar
in another OS. It takes premultiplied colors. Then, suppose we have our
RAGABA, just one pixel, with the following values:
RGB=100,150,200
AAA=100,150,200
If we average AAA we will have (100+150+200)=450/3=150.
But in premultiplied space it's illegal to have component values greater
than alpha. So that, we will need to adjust the color values.
Maybe it makes sense to model it in plain color space first?
Well, on the other hand, imagine you imagine that you can't control the
alpha-blending function. You have only HW accelerated alpha-blend in GPU.
And it needs namely RGBA, premultiplied or not - it doesn't matter.
Your task is to prepare this RGBA. Then, suppose you have one background
pixel, initially set to gray (127,127,127). And your pixel should light only
Red component (to 255), keeping Green and Blue the same. There will be
terrible color fringing, we just ignore it. But that's impossible to do. If
you send RGBA=(255,0,0,255) you will see just pure Red (255,0,0), while you
actually need "dirty red" (255,127,127). There's no way to change one
channel without affecting the other ones using just a standard alpha-blend
operation (src over dst).
The only way is really to use "RAGABA" and after rendering is done, blend it
over RGB (not RGBA).
Actually, it looks like we need to have a "gray-alpha" buffer that we
interpret as RAGABA. I suspect that even image transformation can work with
LCD optimized technique.
> Well, basically it looks like averaging, but it's not that easy.
> Suppose we don't have any AGG stuff and call WinAPI AlphaBlend() or
> something similar in another OS. It takes premultiplied colors. Then,
> suppose we have our RAGABA, just one pixel, with the following values:
> RGB=100,150,200
> AAA=100,150,200
> If we average AAA we will have (100+150+200)=450/3=150.
> But in premultiplied space it's illegal to have component values
> greater than alpha. So that, we will need to adjust the color values.
>
> Maybe it makes sense to model it in plain color space first?
>
> Well, on the other hand, imagine you imagine that you can't control
> the alpha-blending function. You have only HW accelerated alpha-blend
> in GPU. And it needs namely RGBA, premultiplied or not - it doesn't
> matter.
> Your task is to prepare this RGBA. Then, suppose you have one
> background pixel, initially set to gray (127,127,127). And your pixel
> should light only Red component (to 255), keeping Green and Blue the
> same. There will be terrible color fringing, we just ignore it. But
> that's impossible to do. If you send RGBA=(255,0,0,255) you will see
> just pure Red (255,0,0), while you actually need "dirty red"
> (255,127,127). There's no way to change one channel without affecting
> the other ones using just a standard alpha-blend operation (src over
> dst).
The patented ClearType will never affect just one pixel component, but
it will always generate a full RGB triple in order to avoid putting
too much energy into one color, which would be visible to the naked
eye.
The Windows XP implementation of ClearType clearly generates only
the standard ARGB pixels which get then blended by the WIn32 API.
So the big "filtering" work is done before blending.
*But* from what I remember, Windows Vista has a new ClearType engine
which takes benefit of DirectX 9 graphic cards, which know how to
blend individual components. I don't know, however, how this is
represented in memory.
Maybe, checking DirectX 9 blending options would give you some
hints.
> Check COLORWRITEENABLE in DirectX. This allows the selection of a
> specific color channel for the operations. Maybe ClearType blends to
> the channels one after another ? Just a wild guess.
>
> http://www.microsoft.com/whdc/device/display/graphics-reqs.mspxThanks. I however checked another thing.
1. Create 32-bit compatible bitmap and MemDC.
2. Clear it to 0,0,0,0.
3. Draw a ClearType string into MemDC (just TextOut).
4. Call AlphaBlend MemDC -> ClientDC
It doesn't work properly. It looks like it doesn't care about the alpha channel
at all, when drawing.
As soon as you clear the buffer with Alpha=255 everithing works fine. It also
works fine when you use BitBlt instead of AlphaBlend. But as soon as you try to
use a real alpha channel, it fails to display it correctly.
Although, everything drawn with AGG, with properly calculated Alpha works fine.
