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

[Justin Novosad]

Hi Kevin,

The same artifact use to be present in Chrome not that long ago. When we
fixed it, we chose to interpret "original image data" as meaning the part
of the image data that is within the bounds of the of the source rectangle.
Also, it makes more sense to do it that way. I agree that the spec could
use more clarity here.
I support your case that it is preferable for the filtering algorithm to
clamp to the border of the source rectangle rather than to the border the
border of the source image.  This is essential for implementing sprite maps
without having to waste pixels to pad the borders between tiles.

     -Justin Novosad

On Mon, Aug 20, 2012 at 9:38 AM, Kevin Gadd <kevin.gadd at gmail.com> wrote:

> 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
>