- From: Kevin Gadd <kevin.gadd@gmail.com>
- Date: Mon, 20 Aug 2012 06:38:04 -0700
- To: whatwg@lists.whatwg.org
Hi, I've been digging into an inconsistency between various browsers' Canvas implementations and I think the spec might be allowing undesirable behavior here. The current version of the spec says (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawimage): If the original image data is a bitmap image, the value painted at a point in the destination rectangle is computed by filtering the original image data. The user agent may use any filtering algorithm (for example bilinear interpolation or nearest-neighbor). When the filtering algorithm requires a pixel value from outside the original image data, it must instead use the value from the nearest edge pixel. (That is, the filter uses 'clamp-to-edge' behavior.) While clamp-to-edge is desirable, the way this is specified means that it only ever clamps to the edges of the source bitmap, not to the source rectangle. That means that attempting to do the equivalent of css sprites or video game style 'tile sets' - where a single source image contains many smaller images - is not possible, because the spec allows implementations to read pixels from outside the source rectangle. Unfortunately, at present Internet Explorer and Firefox both read pixels from outside the source rectangle, as demonstrated by this test case: https://dl.dropbox.com/u/1643240/canvas_artifacts.html Worse still, in implementations with imageSmoothingEnabled available, turning off image smoothing is not sufficient to eliminate the artifacts. Google Chrome appears to implement this the way you would probably want it to work - by clamping to the edges of the source rectangle, instead of the source image. I can't think of a good reason to prefer the current behavior over what Chrome does, and I haven't been able to find a reliable way to compensate for the current behavior. Thanks, -kg
Received on Monday, 20 August 2012 13:39:14 UTC