- From: Rik Cabanier <cabanier@gmail.com>
- Date: Mon, 10 Dec 2012 13:04:41 -0800
- To: Justin Novosad <junov@chromium.org>
- Cc: whatwg@lists.whatwg.org, Jeff Muizelaar <jmuizelaar@mozilla.com>, Vladimir Vukicevic <vladimir@pobox.com>, Ian Hickson <ian@hixie.ch>, Kevin Gadd <kevin.gadd@gmail.com>
On Mon, Dec 10, 2012 at 11:03 AM, Justin Novosad <junov@chromium.org> wrote: > On Mon, Dec 10, 2012 at 1:24 PM, Ian Hickson <ian@hixie.ch> wrote: > > > > > The reason to prefer the current behaviour is if you want to just update > a > > small part of an image. For example, if you draw a bit photo, then draw > > text over it, then want to remove the text by just drawing the photo over > > where the text was but not redrawing the whole thing. If we clamped to > > source rectangle, we'd get artefacts in this case that couldn't be worked > > around (unlike the problems with scaling sprites, which can be worked > > around, albeit in a suboptimal fashion). > > > > > I disagree. There is an efficient workaround for updating a subregion of an > image without getting filtering artifacts around the edges : use clipping > to limit the update region > How is that an efficient workaround? It involves setting a clip, calling drawimge with a larger (complete?) image and then removing the clip. This seems much more expensive for such as common operation. (ie a game that wants to remove an animated character) > On the other hand, the workaround to prevent color bleeding when using > spritemap is much less efficient since it requires padding, which is > wasteful by definition, and in cases where the sprite can be downsized, the > padding margins may have to be very large. As Ian said, copying the sprite image to a non-scaled canvas first (which most games probably do anyway) works around the issue. There is no need for padding in that case.
Received on Monday, 10 December 2012 21:05:10 UTC