[cairo] Semantics of transparent objects on opaque targets (image
cworth at cworth.org
Fri Jan 13 11:58:29 PST 2006
In finishing up the PostScript output in preparation for the 1.2
release, I've just run into a semantic question, and I'm not quite
sure what the right answer should be.
The question is easiest to ask with the help of some pictures. When
you view the images below, you will want to use a viewer that makes an
obvious distinction between transparent regions as opposed to regions
that happen to be the same color as the background[*].
These images are the result of the operator-clear test from the test
suite with the code that is currently in CVS. The test performs a
similar sequence of operations eight times:
1. Fill a square with a linear gradient pattern ranging from
opaque blue in the upper-right to transparent in the
2. Construct a mask. (Various masks are used: a circle,
glyphs, etc. but the distinction is not significant for the
3. Render that mask using the CLEAR operator.
The simplest result to understand is the result when using a 32-bit
ARGB image surface. The translucence in the gradient-filled square is
quite evident as is the effect of the CLEAR operator which effectively
"punches out" a transparent hole through the previously drawn
Next, let's look at the result with an RGB24 image surface which
obviously does not support any translucence:
The result here may seem a bit surprising at first, since some
portions that were transparent in the ARGB result appear to be blended
against a white background while other transparent portions appear to
be blended against a black background.
That confusing result can be explained because the test suite is
actually performing a slightly different sequence of operations for
RGB24 targets rather than ARGB32. Before running the test, the test
suite initialized RGB24 surfaces with white, while it initializes
ARGB32 surfaces to transparent.
So, against this initial white background, the gradient blends nicely
from blue to white. But the CLEAR operation sets everything within the
mask to black. The effective semantic of the defined arithmetic is
that transparent == BLACK in the land of RGB24.
OK, so with that background, my question is, what should the defined
semantics be for a transparent operation when using the PostScript
backend? For the last while, the PostScript backend has been producing
results that match the RGB24 output. But, with some changes I recently
committed, it now produces a result like this:
Here, all drawing operations are being collected to a
meta-surface. The meta-surface is then replayed to an ARGB32 image
surface. Finally, since PostScript cannot represent an image with
translucence, this image is blended onto an initially-white RGB24
surface and that result is shoved into the PostScript output.
Note that this scheme is temporarily being used for all PostScript
output, but that even as we move to better, more vector-based
PostScript, we still need to nail down the same semantic issue for when
computing image-based fallbacks for portions of the output.
The advantage of this scheme is that operations that put transparency
into the result (such as CLEAR) do actually result in the appearance
of transparency, (in that the white "paper" becomes visible rather
than placing down black ink).
To me, this seems like the right thing to do, but it is a change
compared to what the PostScript result has been up until now, so I
wanted to confirm the decision here on the list before I updated the
reference images for the PostScript output in the test suite.
[*] Something that shows the image rendered against a checkered
background would work well, (the gimp does this by default, and eog
can be made to do so by changing the preferences under the Edit menu).
[**] I'm posting an image here rather than a PostScript file only
because the output at this moment consists of little more than a
PostScript wrapper around an image. For completeness, though, here is
the actual PostScript output that one will currently get from cairo:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060113/4e7787a3/attachment.pgp
More information about the cairo