[whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly

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