[whatwg] Canvas context.drawImage clarification

[Oliver Hunt]

> 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  
something contradictory.

>> 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 
  .

--Oliver

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090709/71d5511f/attachment-0002.htm>