[cairo] Compositing Operations

[jose_ogp at juno.com]

> 
> I think what is being asked here is equivalent to having an 
> opaque 3-channel surface plus a seperate mask, and that the 
> output the user sees is equivalent to the "in" of the target 
> and mask. As described his operators would never change the mask 
> channel, implying that it was created and is modified by some 
> non-cairo api.
> 
> This is not useful for making pre-composited windows and somehow 
> modifying subwindows as the final paragraph I think is describing.
> If the subwindow is not 100% opaque and on top, the destination 
> pixel necessarily contains some mix of that window and all the ones 
> below it, this means it has insufficient information to correctly 
> calculate a new composite.
> 
> There does seem to be a strong belief that windowing systems should 
> work this way, where the "shape" is set up initially and cannot be 
> changed by drawing. Even NeWS worked this way (you used the current 
> path to create a window, and it was always an opaque object of this 
> shape). The NeXT also did this, despite being a true compositing 
> window manager, the windows were defined as rectangles with opaque 
> alpha. I suspect the reason for this thinking is that when designed 
> the memory for storing the alpha per-window was considered wasteful. 
> This thinking has stronly influenced the design of X and Windows.
> 
> However it certainly does not match modern hardware and the ideas 
> of window compositing that are coming with the newest systems at 
> all. In fact it is quite wasteful there, and a much more obvious 
> system would be more efficient and far easier to use, as the same 
> graphics api could control the window shape. I would prefer if a 
> "window" was in fact a 4-channel surface, and zero alpha literally 
> means you can see through it. There may be a rectangular extent, 
> but it would be possible to make this automatically be the extents 
> of the non-transparent area, allowing you to even size the window 
> using cairo. If you want a circular window, you should clear and 
> then draw a circle using cairo. To put a hole in it, the cairo 
> "clear" operator should be all you need. The result is that any 
> antialiasing on the edge is exactly as good as, and precisely 
> matches, the cairo graphics.
> 
> I would prefer that any effort go into emulating such an API on 
> systems that don't support it, rather than trying to match some 
> unchangable-alpha existing system. If this is impossible I would 
> recommend that Cairo only present an opaque (ie no alpha channel) 
> surface and that you be required to use the system api to set the 
> outer border shape, and that the shape be inaccessable from cairo 
> and not influence it's graphics.
> 

	I'm not sure exactly how to respond to most of this... 
Thanks for your thoughts and comments though.

	It's not a necessarily an issue of wether a window is seen
as 3-channel color data on top of a separate alpha mask, or not.
	The algebra of compositing that is given by the Porter-Duff
operators "over", "in", "add", and some others, essentially treat 
all surfaces as 'sub-surfaces' of the surface "1". This is not always 
what one may want.

> Also "rel-add" as described can be done in Cairo by using the 
> destination alpha as a mask.
> 

	Possibly, but it's not clear to me exactly how.. If what you 
mean is first doing an "in" of the src with the dst alpha, and then 
an "add" of that with the dst, one would obtain: 
	rc = min{1, dc + da*sc} 
which is not always the same as 
	rc = min{da, dc + da*sc} 
eg. take dc = da = 1/2, and sc = sa = 1/2. 
 
	If you mean first doing an "add" of src with dst, and then 
an "in" with the original dst alpha, then one obtains: 
	rc = da*(min{1, dc + sc}) 
which again may not give the same results as the above, eg. take 
dc = 1/4, da = 1/2, and sc = sa = 1/2.