Hello, I'm new to the list so I hope this is the right place and format.<br><br>I've been having a look at the canvas tag API specification and I noticed at <br>least one ambiguity. (I'm guessing those that have been on the list for a <br>
while are laughing)<br><br>The specific ambiguity I'd like to bring up has to do with the several versions <br>of a function, context.drawImage. They take width and height values.  The spec <br>does not make it clear what is supposed to happen with negative values.<br>


<br>My personal interpretation and preference is that negative values should <br><br>(a) be legal and <br>(b) draw backward, flipping the image.<br><br>The specification currently says:<br><br>"The source rectangle is the rectangle whose corners are the four points <br>


(sx, sy), (sx+sw, sy), (sx+sw, sy+sh), (sx, sy+sh).<br><br>...<br><br>The destination rectangle is the rectangle whose corners are the four <br>points (dx, dy), (dx+dw, dy), (dx+dw, dy+dh), (dx, dy+dh)."<br><br>Well, simple math would suggest that if sx = 10, and sw = -5 then it still <br>


defines a valid rectangle.<br><br>Unfortunately since the spec is ambiguous the current browsers that implement <br>this all do it differently. Firefox and Opera draw nothing with a negative <br>width or height. Safari and Chrome draw to the rectangle defined by negative <br>


widths and heights but do not flip the image.<br><br>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>


<br>Coming from a graphics and game development background we use the ability to <br>flip images all the time. I know that I can achieve similar results by using a <br>transform matrix but still it would be much easier to just make negative widths <br>


and heights specifically part of the spec.<br><br>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>


<br>Coming from a graphics background I see no reason why if I let my user size an <br>image in a canvas I should have to special case a width or height of zero. Just<br>draw nothing if the width or height is zero. Similarly, if I was to provide a UI <br>


to let a user choose part of the source to copy to the dest and I let them define <br>a rectangle on the source and drag it such that all or part of it is off the <br>source I see no reason why I should have to do extra math in my application to <br>


make that work when simple clipping of values in drawImage would make all that <br>extra work required by each app disappear.<br><br>Another way to look at that is in OpenGL, if my texture coordinates are set<br>less than 0 or greater than 1 the GPU does not fail. Why should drawImage<br>
act any differently?<br><br>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? On top of that the spec<br>does not say what happens at the edges and the different browsers are doing<br>different things. To give you an example, if you take a 2x2 pixel image and<br>


scale it to 256x256 using drawImage. All the major browsers that currently <br>support the canvas tag will give you an image where the center of each pixel is <br>around center of each 128x128 corner of the 256x256 result. The area inside the <br>


area defined by those 4 points is rendered very similar on all 4 browsers. The <br>area outside though, the edge, is rendered very differently. On Safari, Chrome <br>and Opera the colors of the original pixels continue to be blended all the way to<br>


the edge of the 256x256 area. On Firefox though, the blending happens as though <br>the source image was actually 4x4 pixels instead of 2x2 where the edge pixels <br>are all set to an RGBA value of 0, 0, 0, 0. It then draws that scaled image as <br>


as though the source rectangle was sx = 1, sy = 1, sw = 2, sh = 2 so that you <br>get a progressively more and more translucent color towards the edge of the <br>rectangle.<br><br>I don't know which is right but with low resolution source images the 2 give <br>

vastly different results. <br><br>Could these ambiguities be clarified in the spec?