Context drawImage blurs images when offset by decimal amount

RESOLVED INVALID

Status

()

Core
Canvas: 2D
--
minor
RESOLVED INVALID
8 years ago
8 years ago

People

(Reporter: Paris Holley, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
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>
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?
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?).
(Reporter)

Comment 3

8 years ago
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.
> 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?
(Reporter)

Comment 5

8 years ago
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.
Mailing whatwg@lists.whatwg.org should work.  I don't think this is particularly implementation-dependent as an issue.
(Reporter)

Comment 7

8 years ago
Ok, I will follow up with them and mark this issue as INVALID.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.