- From: Justin Novosad <junov@chromium.org>
- Date: Mon, 17 Dec 2012 10:23:30 -0500
- To: Rik Cabanier <cabanier@gmail.com>
- 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 Sun, Dec 16, 2012 at 11:52 PM, Rik Cabanier <cabanier@gmail.com> wrote: > > > On Wed, Dec 12, 2012 at 10:24 AM, Justin Novosad <junov@chromium.org>wrote: > >> >> >> On Wed, Dec 12, 2012 at 12:39 PM, Rik Cabanier <cabanier@gmail.com>wrote: >> >>> >>> What would be the next step? Should we define a new version of drawImage >>> with the extra parameter? >> >> >> That is one option, but I think a context attribute (like >> imageSmoothingEnabled) is also worth considering. >> Perhaps image smoothing could be an enum rather than boolean with an >> additional mode that prevents color bleeding. >> > > It seems a bit too expensive to add a variable to the graphics context > that is checked for just this call. > Maybe just a new drawImage call (like drawNonSmoothedImage?) is all that > is needed. > Yes. That sounds quite reasonable to me, but we can find a better name. The name "drawNonSmoothedImage" suggests that the image won't be smoothed at all, which is not the case. It's hard to find a name that correctly describes the right behavior without getting too technical. I am thinking "drawSubImage", in the sense that the sub region delimited by the source rectangle is treated as if it were a whole image. 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. > > >> >> >>> If so, we probably want the description of the existing drawImage call >>> to change so it leaves the resampling issue undefined unless WebKit is OK >>> with changing their current behavior. >>> >> >> IMHO: Undifined behavior is a spec bug. If we have a problem with the >> spec, we fix the spec, we don't just each do our own thing. >> >> >
Received on Monday, 17 December 2012 15:24:05 UTC