Compositing and alpha

[Alexander Malmberg]

Recently I've implemented better compositing support in back-art,
including most operators in the non-compositerect case. There's a pretty
picture of it all at:

http://w1.423.telia.com/~u42308495/alex/backart/backart_composite.png

(For those who care, back-art and, thus, this picture are using
pre-multiplied alpha. Sover-compositing the results of the composite on
a black background would look like in the picture even with
non-premultiplied alpha, so you can pretend that that's the case.)

The results are correct, as far as I can tell. Anyway, a few questions:

1.
Currently, when you render with alpha in back-art, the stuff you render
gets blended over the stuff that's already there. Another way of dealing
with alpha would be to simply replace when drawing, including the alpha
buffer. Some DPS docs I've found seem to imply this. I'm not sure what
mosx does. What should GNUstep do?

Eg.:

PSsetalpha(1);
PSsetrgbcolor(1,0,0);
PSrectfill(0,0,100,100);
PSsetalpha(0.5);
PSsetrgbcolor(0,0,1);
PSrectfill(25,25,50,50);

Should the middle rectangle be a 50/50 blend of red and blue with alpha
1, or all blue with alpha 0.5?

2.
How do PlusD and PlusL work, especially wrt alpha?

3.
The docs I have say that compositerect with the normal operators should
work like a composite from a window filled with the current color. This
isn't currently implemented, and implementing it would be a fair amount
of (straightforward but boring) work. Does mosx have something
equivalent? Will the 'final' GNUstep backend interface? It would be a
useful feature if drawing with alpha doesn't blend, but I hope we will,
and then there's no big use for it.

4.
What's the initial contents of a window? Currently I'm assuming that
it's all opaque since this lets me optimize handling of completely
opaque windows (ie. basically all on-screen windows).

5.
Is DPSimage supposed to do a plain blit of color and alpha data to a
window, or blend the image (an Sover composite, in practice)?

- Alexander Malmberg