[cairo] Cairo gradients and pre-mul data

[Carl Worth]

On Tue, 20 Jun 2006 21:58:31 GMT, "jose_ogp at juno.com" wrote:
> 	While Cairo seems to be faithfully committed to using 
> alpha-pre-multiplied color data when transforming and compositing 
> 'surfaces', it seems that when generating the 'spectrum' of a 
> gradient it assumes non pre-mul color data, does its linear 
> interpolation with such, and only then pre-muls the results. 

When providing (or reading) image data to/from cairo that contains
both color and alpha content, the only currently available image
format (CAIRO_FORMAT_ARGB32) does use pre-multiplied color, yes.

The other places that color with alpha gets fed to cairo are not
related to image data, and consist of the following APIs:

	cairo_set_source_rgba
	cairo_add_color_stop_rgba

As you noticed, the second call (used with gradients) accepts a
non-premultiplied color. But, perhaps you didn't notice that the first
call (which is used for setting "solid", non-gradient colors) also
accepts a non-premultiplied color.

> 	While it's true that one can't obtain the same results if 
> one were to pre-mul the input color data (or require them pre-mul) 
> and do the linear interpolation with such, that alone is insufficient 
> reason for not doing so. I would suspect that the current semantics, 
> differing from the rest of Cairo, would be unwise... 
>  
> 	What is the actual overriding reason that decided Cairo 
> on using its current approach for gradients? 

This is actually an open issue that has been bothering me for some
time. A little over a year ago, and before the 1.0 release, we did a
careful scan of the cairo API looking for things we wanted to change
as a last chance before freezing on API we would be committing to
maintain "forever".

When we did that scan I noticed this issue that cairo accepted both
pre- and non-premultiplied colors in different parts of the API. So I
made a proposal that would have also added two variations of the
above:

	cairo_set_source_rgba_premultiplied
	cairo_add_color_stop_rgba_premultiplied

Here's that first proposal:

	http://article.gmane.org/gmane.comp.lib.cairo/2797 [*]

I even attempted an implementation of the idea:

	http://article.gmane.org/gmane.comp.lib.cairo/3438

but then we ran into a problem with the interpolation of gradient
color stops specified with pre-multiplied values:

	http://article.gmane.org/gmane.comp.lib.cairo/3458

In particular, (as noted in the message above), with stops specified
as pre-multiplied color values, there's no way specify a gradient that
smoothly blends from red to blue (say) while also blending from alpha
1.0 to alpha 0.0. This turns out to be a very useful thing to do, and
is easy to specify with non-premultiplied color, (which also happens
to match how gradients are specified in SVG, for example).

So it seems we hit a fairly fundamental problem with pre-multiplied
color stops. We could still add the proposed API back as long as it
comes with clear specifications on what the semantics should be. I
asked last April if anybody had any proposal for what these semantics
should be, but nobody had brought up the issue again until now, (as
far as I recall).

But I don't think there's any real inconsistency in cairo right now.
(Admittedly, there is a sentence or two missing from the documentation
to indicate that set_source_rgba and add_color_stop_rgba expect
non-premultiplied color values.)

-Carl

[*] I would prefer to send pointers to archived messages on the server
that we actually, maintain, but the archives continue to be
non-functional. For example, here are what would be the same three
messages on the freedesktop.org server:

http://lists.freedesktop.org/archives/cairo/2005-February/003050.html
http://lists.freedesktop.org/archives/cairo/2005-April/003683.html
http://lists.freedesktop.org/archives/cairo/2005-April/003703.html

The second message here is totally broken, (which appears to be a
common symptom for a signed message with an attachment---which happens
to be not a small percentage of the mail I send to the cairo
list). I'd love to hear that pipermail has acquired a fix for this
bug, or to otherwise here some advice on how to fix our archive.

Also, as I've mentioned several times before, I'd prefer an archiver
that would properly thread messages. Click on the subject line of any
of the gmane views of the messages above to see proper threading. Then
try following the thread links in the freedesktop messages and see
that the thread is broken when it crosses the boundary between
February and April.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20060620/be96b3de/attachment.pgp