[cairo] Compositing Operations

Bill Spitzak spitzak at d2.com
Mon Feb 27 12:26:12 PST 2006


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.

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


More information about the cairo mailing list