[cairo] State of Win32 backend?

[Owen Taylor]

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:

Looks good.

> 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?

Thanks,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050509/fc810bd5/attachment.pgp