[cairo] State of Win32 backend?
otaylor at redhat.com
Mon May 9 17:10:32 PDT 2005
On Fri, 2005-05-06 at 02:02 +0300, Tor Lillqvist wrote:
> Owen Taylor writes:
> > No, this isn't right. You'll compute 0xffff * 0xffff >> 8. The
> > "0xffff *" isn't needed when you are using red_short.
> OK, should have used my brain ;-)
> > Don't understand why you removed this.
> I guess I thought that as the alpha wasn't longer where it used to be,
> that it wasn't necessary, or something...
> So, the current diff would then be this simple:
> new_color = RGB (((int)(0xffff * solid_pattern->red)) >> 8,
> - ((int)(0xffff * solid_pattern->green)) >> 8,
> - ((int)(0xffff * solid_pattern->blue)) >> 8);
> + /* XXX Use the unpremultiplied or premultiplied color? */
> + new_color = RGB (((int)solid_pattern->color.red_short) >> 8,
> + ((int)solid_pattern->color.green_short) >> 8,
> + ((int)solid_pattern->color.blue_short) >> 8);
This XXX is a very good question.
When we draw with operator SOURCE and < 1.0 alpha onto a
no-alpha destination, what are the resulting color values?
Using the premultiplied colors is consistent with the behavior of the
image/RENDER backends, and while it isn't *useful* behavior
(♫ paint it black) it avoids the problem of what to do for
alpha == 0.
It also avoids expensive checks when painting ARGB (alpha == 1.0)
images onto a RGB surface.... we can just blast the pixels.
If you have commit access (if you don't, you should :-), go ahead and
commit. Otherwise, can you provide the patch as an attachment?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050509/fc810bd5/attachment.pgp
More information about the cairo