- From: Rik Cabanier <cabanier@gmail.com>
- Date: Wed, 12 Dec 2012 09:39:40 -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 Tue, Dec 11, 2012 at 7:56 AM, Justin Novosad <junov@chromium.org> wrote: > > > On Mon, Dec 10, 2012 at 6:53 PM, Rik Cabanier <cabanier@gmail.com> wrote: >> >> >> I assume this would only be for the 9 argument version of drawImage? >> > > Yeah, the all dressed version. > > >> >> FWIW >> I was curious why this bug doesn't show up in WebKit so I looked at the >> implementation. >> They actually catch cases where there's scaling of a portion of an image >> and special case it by copying the non-scaled image to a temporary canvas >> first: >> // When the image is scaled using high-quality interpolation, we >> create a temporary CGImage >> // containing only the portion we want to display. We need to do >> this because high-quality >> // interpolation smoothes sharp edges, causing pixels from >> outside the source rect to bleed >> // into the destination rect. See <rdar://problem/6112909>. >> >> It would be nice to see why the Safari folks added this code since it >> makes them inconsistent with the spec. >> >> > For the skia port of WebKit (used by Chrome) clamping to the source region > is built into the blitter functions (sw rendering) and shaders (gpu > rendering) so that color bleeding can be prevented without creating a > temporary copy of the image. The reason it was implemented this way is > that the bleeding was reported as a bug by game developers and the spec was > not as clear then as it is today. > > We were getting more complaints about this issue back when there was color > bleeding, which is the main reason why I have been arguing in favor of > clamping to the bounds of the source rectangle. It seems more web > developers are getting the results they expect from drawImage now that > there is no color bleeding in Chrome, which is unfortunately not spec > compliant behavior. > > What would be the next step? Should we define a new version of drawImage with the extra parameter? 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.
Received on Wednesday, 12 December 2012 17:40:13 UTC