[whatwg] Canvas context.drawImage clarification
oliver at apple.com
Thu Jul 9 18:25:07 PDT 2009
> 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.
API behaviour is not effected by the DOCTYPE, only parsing.
Unfortunately you can't change a DOM API that has existed for years to
>> 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.
If you believe that to be the case then you can always file a bug at bugs.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg