W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] Canvas context.drawImage clarification

From: Gregg Tavares <gman@google.com>
Date: Thu, 9 Jul 2009 18:16:55 -0700
Message-ID: <de4bd3190907091816u66cad478gbdd0093e41ad0782@mail.gmail.com>
On Thu, Jul 9, 2009 at 4:28 PM, Oliver Hunt <oliver at apple.com> wrote:

>
> On Jul 9, 2009, at 4:19 PM, Gregg Tavares wrote:
>
>
>
> On Thu, Jul 9, 2009 at 4:11 PM, Oliver Hunt <oliver at apple.com> wrote:
>
>>  I'd like to make a passionate plea that the spec say "implementations
>>> must
>>> support negative widths and negative heights and draw the image backward
>>> effectively flipping the result".
>>>
>>
>> We'd need to be fairly sure that such a change would not break existing
>> content -- this is a change that would result in substantially different
>> rendering in some scenarios.
>>
>
> Given that it's inconsistent in the various browsers it's hard to see how
> this would break something since it's broken in 2 browsers one way or the
> other currently.
>
>
> Inconsistency doesn't lead to no one depending on a behaviour, it just
> means sites only work in one browser.  Your suggesting would result in sites
> being broken in all browsers -- the only options from here on out are either
> nothing gets drawn (as in gecko and presto), or the destination is
> normalised (as in webkit).
>

Or making it consistent when the DOCTYPE is set to something.


>
> Image scaling is implementation dependent everywhere else, why would it be
>> spec defined in the case of canvas?
>
>
> There are 2 issues here I brought up
>
> 1) What happens at the edges.
>
> The results are VASTLY different now. Unless this works consistently it
> would be hard to make canvas graphics work across browsers and expect get
> reproducible results.  The 2x2 pixel example I gave, one browser ends up
> scaling with translucency even though there is no translucent pixels in the
> source image.
>
>
> This is just an artifact of scaling, and you agree below that scaling is
> implementation dependent.
>

I disagree. When I scale a rectangular opaque image I expect rectangular
opaque results.  The Firefox implementation does not do this. If I take a
1x1 pixel image and attempt to use it to cover up something in another image
by scaling it it will not cover up that other image. Only the very center
pixel will be opaque, all other pixels will be some percentage translucent,
showing whatever was previously drawn on the canvas.  That's a much bigger
issue than whether the scaled pixels are blocky or smooth.





>
>
> 2) How it does the scaling.
>
> I agree that it being implementation dependent is probably fine.
>
>
>
>>
>> --Oliver
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090709/911f040d/attachment.htm>
Received on Thursday, 9 July 2009 18:16:55 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC