595850 - Context drawImage blurs images when offset by decimal amount

Status: RESOLVED INVALID

(Core :: Graphics: Canvas2D, defect)

Description

[Paris Holley]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.53 Safari/534.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9

When drawing an image on canvas using a offset which is a decimal value ( 10.5 vs 10 ), the image becomes blurred and "mozImageSmoothingEnabled" must be used to prevent. Obviously, the work around is to either round any calculated numbers or use that extension, but other browsers do not exhibit this behavior.

Reproducible: Always

Steps to Reproduce:
<canvas id="canvas1" width="500" height="500"></canvas>
<canvas id="canvas2" width="500" height="500"></canvas>

<script type="text/javascript">
	window.onload = function(){
		var canvas1 = document.getElementById("canvas1");
		var canvas2 = document.getElementById("canvas2");

		var image = new Image();
		image.onload = function(){	
			canvas1.getContext("2d").drawImage(this, 10, 10);
			canvas2.getContext("2d").drawImage(this, 10.5, 10.5);
		};

		image.src = "image.png";
	}
</script>

Comment 1

[Boris Zbarsky [:bzbarsky]]

You're asking for pixels of the image to be drawn on pixel boundaries; the only way to do this is to either antialias them, draw them 2x wide instead of 1px, or draw them someplace other than where you asked them to be drawn.

Which of those latter two do the browsers that don't antialias do?

Comment 2

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I'd be surprised if other browsers don't do this; if they don't, that likely means they have bilinear filtering turned off for canvas (possibly for higher benchmark scores?).

Comment 3

[Paris Holley]

Chrome doesn't do this but you are right, its probably because anti-aliasing isn't enabled by default ( haven't looked into it). For certain canvas calls, I would expect odd but documented behavior for if it decides to draw 2px wide, antialias them, etc. 

However, when offseting an image, I would not expect it to blur, be a pixel off to the left or right perhaps, or even antialias the edge that is along the boundries of the offset, but when the entire thing blurs, I would expect that to be documented (or at least provided by the canvas spec, but that almost never includes implementation details)

In the end, not a big deal, can just round calculations and my problem is solved, but I've got to wonder about more complex canvas solutions that would include dynamicly driven positioning/scaling, etc with images and how this would affect that.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> or even antialias the edge that is along the boundries of the offset

But the edge isn't the only thing that falls between two pixels of the canvas.  The call is asking for _every_ pixel of the image to be painted between two canvas pixels, right?

Snapping could be done, but would give the wrong rendering, in general...  I agree the blurring is suboptimal, but as long as the underlying resolution of the canvas matches the screen resolution and also matches CSS px, there are no good options here.

I agree that the spec should define this.  Do you want to raise the issue with the spec folks, or should I?

Comment 5

[Paris Holley]

Ah, that makes more sense. If it applies the offset to each drawn pixel, then I suppose its the lesser of both evils depending on which way it is implemented.

What is the proper way to raising the issue with them? Unless you feel having knowledge of the underlying implementation would help aid in providing details to the spec folks on how this "feature" should be described, then you probably should.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Mailing [e-mail] should work.  I don't think this is particularly implementation-dependent as an issue.

Comment 7

[Paris Holley]

Ok, I will follow up with them and mark this issue as INVALID.