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

[Rik Cabanier]

Hi Kevin,

can you log a bug on this?  https://www.w3.org/Bugs/Public/enter_bug.cgi
once it's in the system, we can fix the wording in the spec.

Rik

On Mon, Aug 20, 2012 at 6: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
>