- From: Rik Cabanier <cabanier@gmail.com>
- Date: Mon, 10 Dec 2012 15:53:08 -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 1:18 PM, Justin Novosad <junov@chromium.org> wrote:
> On Mon, Dec 10, 2012 at 4:04 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
>>
>>
>> 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.
>>
>>
> Yes, I am sure a lot of games do it already to work around the color
> bleeding problem but there is a performance cost to doing that.
>
> Couldn't we just make everyone happy by making the behavior controllable
> through a context attribute or an additional overload of drawImage that
> takes an extra argument?
>
I assume this would only be for the 9 argument version of drawImage?
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.
Received on Monday, 10 December 2012 23:53:35 UTC