<br><br><div class="gmail_quote">On Thu, Jul 9, 2009 at 4:11 PM, Oliver Hunt <span dir="ltr"><<a href="mailto:oliver@apple.com">oliver@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'd like to make a passionate plea that the spec say "implementations must<br>
support negative widths and negative heights and draw the image backward<br>
effectively flipping the result".<br>
</blockquote>
<br></div>
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.<div class="im"></div></blockquote><div><br>
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.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Also, I'd like to suggest that a widths and heights of 0 for source should be<br>
valid as well as rectangles outside of the source also be valid and that this<br>
part of the spec.<br>
<br>
"If the source rectangle is not entirely within the source image, or if one of<br>
the sw or sh arguments is zero, the implementation must raise an INDEX_SIZE_ERR<br>
exception."<br>
<br>
be changed to reflect that.<br>
</blockquote></div>
The issues of when exceptions should be thrown in the canvas API have been discussed repeatedly on this list, you should search the archives and see if there are any arguments you can make that have not already been made. (I note that i am also all for exceptions not being thrown in many of these cases)</blockquote>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The next issue related to drawImage is that the spec does not specify how to<br>
filter an image when scaling it. Should it use bi-linear interpolation? Nearest<br>
Neighbor? Maybe that should stay implementation dependent?<br>
</blockquote></div>
Image scaling is implementation dependent everywhere else, why would it be spec defined in the case of canvas?</blockquote><div><br>There are 2 issues here I brought up<br><br>1) What happens at the edges. <br><br>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. <br>
<br>2) How it does the scaling. <br><br>I agree that it being implementation dependent is probably fine.<br><br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><font color="#888888">
<br>
--Oliver<br>
<br>
<br>
</font></blockquote></div><br>