[whatwg] Need clarification on DOM exceptions thrown by canvas 2D drawImage

[Philip Taylor]

On Mon, Aug 8, 2011 at 10:08 PM, Jeff Muizelaar <jmuizelaar at mozilla.com> wrote:
>
> On 2011-08-08, at 4:58 PM, Ian Hickson wrote:
>
>> On Mon, 8 Aug 2011, Justin Novosad wrote:
>>>
>>> This inquiry is regarding this page of the specification:
>>> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html
>>> In section 4.8.11.1.10 Images, about drawImage(), it is stated that "If
>>> one of the sw or sh arguments is zero, the implementation must raise an
>>> INDEX_SIZE_ERR exception"  There are no other references to other
>>> circumstances under which INDEX_SIZE_ERR should be thrown, and there is
>>> no indication of what the correct behavior is when the source rectangle
>>> is completely or partially outside the bounds of the source image.

The spec used to throw exceptions on out-of-bounds source rectangles,
but that causes breakage because floats are imprecise (e.g.
http://www.jigzone.com/xmockup/oCanvasBug.php failed in Opera because
79.00000000000001 > 79 as 64-bit double, whereas other browsers
presumably rounded to 32-bit float first), so it had to be changed.
(http://html5.org/r/5373 first, then changed again because of
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10799 to be consistent
with filtering behaviour.)

>> A bit lower down in the same section, the spec says: "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.)"
>
> The clamp-to-edge behavior doesn't really work well with Coregraphics' drawImage call. This means that this behaviour is not implemented in Firefox on OS X and I expect WebKit doesn't implement it for a similar reason. I was actually hoping the spec could be changed to the simpler behaviour of just clamping the source rectangle to the bounds of the image. This behaviour is easy to implement on all platforms and is still quite reasonable.

Does the clamp-to-edge behaviour work fine when the source rectangle
is entirely inside the image? e.g. the image

8800
8800
0088
0088

(where each digit is a pixel) drawn at 2x scale with bilinear
filtering should give

88862000
88862000
88862000
66653222
22235666
00026888
00026888
00026888

because of the filtering requirements. If CoreGraphics can't do that
then it's broken (per the spec) regardless of how source rectangles
are handled. Or is it able to do clamp-to-edge fine up to the edge of
the source image, just not extend that beyond the image when the
source rectangle is expanded further?

-- 
Philip Taylor
excors at gmail.com