Q:  There seems to be a problem with compositing. Using  the CompositeLab in /NextDeveloper/Examples on a 2-bit screen, set the following parameters and use the SOVER operation:

	Source gray=1  opacity=0.3 (white mostly transparent source)
	Dest   gray=0.8 opacity=1   (light gray opaque destination)

You will see that the result is the same color as the destination. Thus the 30% coverage from the white source is having no effect at all!  Now change the source opacity to 0; this causes no change in the result.  What's going on here?

A:  The behavior is correct. Assume the case where the source is all white and is 33% opaque.  Say the destination is 66% white and opaque. (This assures that we are using exact pixel values with no dithering.) The SOVER formula is:

	sourceColor * sourceOpacity + destColor * (1 - sourceOpacity)

which for our case reduces to 

	1 * 1/3 + 2/3 * 2/3 = 7/9

which is rounded to 6/9, given that compositing only works on a per-pixel basis. Changing the opacity all the way down to 0 simply changes the resulting pixel to 6/9, thus no color change occurs.

Now using the parameters in the question

	Source gray=1  opacity=0.3 (white mostly transparent source)
	Dest   gray=0.8 opacity=1   (light gray opaque destination)

We see that there are some source pixels with opacity of 0, and a few with opacity of 1/3. Source color is 1 in all cases. There are some dest pixels with gray of 1 and others with 2/3; opacity is 1 in both cases.

Thus every resulting pixel is computed from one of four formulas:

sourceColor * sourceOpacity + destColor * (1 - sourceOpacity)
1	*	0	+	1	*	(1 - 0)	= 1
1	*	1/3	+	1	*	(1 -1/3)	= 1
1	*	0	+	2/3	*	(1 -0)	= 2/3 
1	*	1/3	+	2/3	*	(1 -1/3)	= 7/9

Thus the result is equal to the dest color in all cases. 

If you wish to composite in a more accurate fashion, you can use 8-bit deep grayscale windows. However, this will use up a lot more memory and is probably not worth it.

QA712

Valid for 2.0, 3.0