[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