[whatwg] inconsistent canvas implementations of destination-in compositing
David Karger
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.
David Karger
example inline.
<!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>
Darin Adler
> 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