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

[Rik Cabanier]

On Mon, Dec 17, 2012 at 2:42 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Tue, Dec 18, 2012 at 4:23 AM, Justin Novosad <junov at chromium.org>wrote:
>
>> This gives me another
>> idea: we could just have a new Image constructor that creates a new image
>> element that is a subregion of another:
>> var mySprite = new Image(spriteMap, x, y, w, h);
>> This can be implemented in a lightweight way that just references the data
>> of the source image.
>>
>
> I like this idea. It means that implementations that need to make a copy
> of the data can make a copy and associate it with the new Image object ---
> which seems more straightforward than a drawSubimage call, where such
> implementations would have to cache subimages internally.
>
> This approach also avoids having to define how subimages would behave for
> video elements, canvases, etc.
>
> This approach is also more generally useful than a drawSubimage call or a
> new drawImage parameter.
>

This looks like the ideal solution.
Does it matter that this solution is in the image world and not 2d canvas?
It seems that this will have a bigger impact on the browser's codebase
since it spans images and canvas.

I still think there's value in being smart when doing drawimage but the
benefits might not be worth the effort.


>
> We would have to define how this subimage constructor works for an
> animated image. I suggest it should return a non-animated subimage of the
> first frame.
>
> I think the main risk of this approach is that it requires Web apps to opt
> into it instead of changing the spec to match what Chrome is currently
> doing, so it doesn't solve the immediate problem of Web apps that currently
> work in Chrome not working in other browsers. Chrome changing behavior to
> match the spec would solve this. Can that happen quickly, please? :-)
>

yes!