[whatwg] Canvas: clarification of compositing operations needed

James Robinson wrote:
> On Wed, Jul 28, 2010 at 2:46 PM, Tab Atkins Jr. <jackalmage at gmail.com 
> <mailto:jackalmage at gmail.com>> wrote:
> 
>     On Wed, Jul 28, 2010 at 2:43 PM, David Flanagan
>     <david at davidflanagan.com <mailto:david at davidflanagan.com>> wrote:
>      > Firefox and Chrome disagree about the implementation of the
>      > destination-atop, source-in, destination-in, and source-out
>     compositing
>      > operators.  Test code is attached.
> 
> 
> I don't think your attachment made it through. 
>  https://developer.mozilla.org/samples/canvas-tutorial/6_1_canvas_composite.html shows 
> some of the differences, although it does not cover all cases.

You didn't miss much.  My example was very similar to the one you link to.

> 
> The spec is certainly clear but that does not make the behavior it 
> specifies good.  I find the spec's behavior pretty bizarre and Microsoft 
> has expressed a preference for the Safari/Chrome 
> interpretation: http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/0046.html - 
> although that thread did not get much discussion.  

Thanks for that link.  The thread you reference refers back to an 
earlier thread on this list.  My apologies for not finding it and 
reading it before posting again.

For example, I think
> drawing a 20x20 image into a 500x500 canvas without scaling with a 
> globalCompositeOperation of 'copy' should result in only the 20x20 
> region being cleared out, not the entire canvas.

Yikes!  It hadn't occurred to me that copy should behave that way.  But 
you're right that that is what the spec requires.  Opera does it that 
way.  Firefox, thankfully, does not.

Perhaps independently of the debate over infinite bitmap vs. shape 
extents, we can agree that "copy" is a special value that means "do not 
perform compositing"

	David

Received on Wednesday, 28 July 2010 23:39:06 UTC