Problems:

1.  
The alpha window concept from SC1200 does not exist on Xilleon.
The Xilleon instead has a per pixel alpha plane. To support the
alpha windows the DirectFB window subsystem is hacked to support
a special window which handles the alpha window drawing.
Alpha window coordinates are set with a special DirectFB function.

Alpha values in the frame buffers are used both to blend graphic and
video. There are two ways to do video and graphics mixing:

Multiplicative mode:
   Output = Video * (1 - alpha) + Graphics * alpha

Additive mode:
   Output = Video * (1 - alpha) + Graphics
   
Currently all X graphics is drawn with alpha 0, so if the first mode
is used, all graphics will be invisible. This is why we are currently
using additive mode and doing the graphics blending for each alpha
window.


2.
The color key concept from SC1200 where video is shown in matching
areas does not exist on Xilleon. Nor does solid color alpha windows (a
solid color is a color connected to an alpha window that will be
rendered on a color key match inside the alpha window).  On the other
hand the Xilleon can do both destination and source color keying when
bliting graphics surfaces and destination color keying when
drawing. It can also do inverse color keying, that is match everything
this is not equal to the color key.  This is the basic strategy to get
SC1200 style color keying on Xilleon:

c1. Copy the destination region to a scratch buffer. The buffer is a full 
screen frame in video memory.
c2. Use inverse destination color keying to fill the parts of the buffer
that does not match the color key with some color C that is different from
the color key and all solid colors.
c3. Use destination color keying to fill the rest of the buffer with solid
colors or just transparent.
c4. Do the normal blending procedure.
c5. Blit the scratch surface with inverse source color keying with the
color C as key. This will replace all graphics that matched the color key
with solid color values or transparency (so that video is displayed).

Why not just draw the color key area directly and avoid the scratch buffer?
This is not possible as the blending procedure will change the color values
in alpha windows and make the color key matching fail.


3. 
The Sigma OSD overlay concept does not exist on Xilleon. This is solved
by using the a DirectFB window that is placed above the X graphics. 
This is actually the same window as the one used for alpha windows.
A special DirectFB function is used to set the size of the overlay as
the alpha window is always fullscreen.
There are several problems with the overlay:

* The overlay must be clipped against the video window. This is actually a
unnecessary limitation but it exist on SC1200/Sigma.

* The overlay should be placed under alpha windows. Currently it is just
clipped.

* The overlay should only be shown in matching areas when using color
keying. This does not work at the moment.


--------------------------------------------------------------------------


Summary of the whole procedure:

Step 1:
If we are using color key copy the destination region to a scratch buffer. 
Use inverse destination color key to fill with a color that is not used as
color key or solid color. Use destination color key to fill the rest of the
surface with solid colors or just transparent black.

Step 2:
Blend destination graphics with source alpha from alpha windows.

Step 3:
Set alpha values for video, just copy the alpha value from the alpha windows
to the alpha plane. This is done with a hack in the dfbdriver so the write mask
is changed so only alpha values are touched.

Step 4:
If color key is used, blit scratch surface with inverse source color key.

Step 5:
Draw overlay if it is enabled. It is clipped against the video window and alpha
windows.



