James Robinson wrote:
On Wed, Jul 28, 2010 at 2:46 PM, Tab Atkins Jr. <jackalm...@gmail.com <mailto:jackalm...@gmail.com>> wrote:

    On Wed, Jul 28, 2010 at 2:43 PM, David Flanagan
    <da...@davidflanagan.com <mailto:da...@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

Reply via email to