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
