- From: Justin Novosad <junov@chromium.org>
- Date: Tue, 11 Dec 2012 10:56:23 -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 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.
Received on Tuesday, 11 December 2012 15:56:56 UTC