W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2012

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

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 17 Dec 2012 21:57:48 -0800
Message-ID: <CAGN7qDBwRFtytGLfs1rskhn-oteELEY8gnm0Ya2gV+YYB0qyqQ@mail.gmail.com>
To: robert@ocallahan.org
Cc: Vladimir Vukicevic <vladimir@pobox.com>, Kevin Gadd <kevin.gadd@gmail.com>, Justin Novosad <junov@chromium.org>, whatwg@lists.whatwg.org, Jeff Muizelaar <jmuizelaar@mozilla.com>, Ian Hickson <ian@hixie.ch>
On Mon, Dec 17, 2012 at 2:42 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Tue, Dec 18, 2012 at 4:23 AM, Justin Novosad <junov@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? :-)

Received on Tuesday, 18 December 2012 05:59:19 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:50 UTC