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?).
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?
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 firstname.lastname@example.org should work. I don't think this is particularly implementation-dependent as an issue.
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.