[whatwg] inconsistent canvas implementations of destination-in compositing

It looks like whatwh strips attachments, so I am resending with the 
example inline.

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.

I enclose a small html document demonstrating the inconsistency.  Just 
open it in firefox and chrome.

<!DOCTYPE HTML>
<html>
<head>
<title>
Canvas test
</title>

</head>
<body>
<h1>Canvas destination-in Compositing Test</h1>
canvas 1:
<div>
<canvas id="c1"></canvas>
</div>
canvas 2:
<div>
<canvas id="c2"></canvas>
</div>
<script>
var c1=document.getElementById("c1");
c1.width=50; c1.height=50;
var k1=c1.getContext("2d");
k1.fillStyle="#0000FF";
k1.fillRect(0,0,25,25);

var c2=document.getElementById("c2");
c2.width=100; c2.height=100;
var k2=c2.getContext("2d");
k2.fillStyle="#FF0000";
k2.fillRect(0,0,75,75);

k2.globalCompositeOperation="destination-in";
k2.drawImage(c1,0,0);
</script>
</body>
</html>

Received on Thursday, 22 December 2011 10:36:58 UTC