[whatwg] I believe source rectangles for HTML5 Canvas drawImage are specified incorrectly

Justin Novosad junov at chromium.org
Tue Dec 11 07:56:23 PST 2012


On Mon, Dec 10, 2012 at 6:53 PM, Rik Cabanier <cabanier at 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.



More information about the whatwg mailing list