[whatwg] inconsistent canvas implementations of destination-in compositing

[Darin Adler]

On Dec 22, 2011, at 10:35 AM, David Karger wrote:

> Firefox and chrome inconsistently handle "destination-in" compositing; I suspect this may be due to a missing specification in the standard.  The inconsistency happens when I use the drawImage method to draw one canvas onto another while the globalCompositionOperation is set to "destination-in"  .  Under destination in, pixels in the destination canvas should be left alone where the source canvas has a set pixel and cleared where the source canvas has a cleared/transparent pixel.
> 
> Both browsers do this properly inside the range of the source canvas.  But if the source canvas has smaller dimensions than the destination canvas, they inconsistently handle parts of the destination canvas _outside_ the source canvas: firefox clears those pixels while chrome leaves them alone.  I believe the standard isn't clear on what should happen in this case.   I'd say that firefox's behavior is more consistent with the intent of "destination-in", but obviously cross-platform consistency is the most important consideration.

It sounds like the Chrome behavior you are describing is a symptom of this WebKit bug, fixed in the WebKit source code on 2011-10-26:

https://bugs.webkit.org/show_bug.cgi?id=66920
Canvas drawImage with SourceIn, DestinationIn, SourceOut, DestinationAtop and Copy have errors

-- Darin