<br><br><div class="gmail_quote">On Mon, Jul 27, 2009 at 3:12 PM, Ian Hickson <span dir="ltr"><<a href="mailto:ian@hixie.ch">ian@hixie.ch</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">On Thu, 9 Jul 2009, Gregg Tavares wrote:<br>
><br>
> The specific ambiguity I'd like to bring up has to do with the several<br>
> versions of a function, context.drawImage. They take width and height<br>
> values. The spec does not make it clear what is supposed to happen with<br>
> 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>
</div>Correct. Why is this ambiguous? The rectangle is well-defined, it just<br>
happens that its points are given in a different order than normally.</blockquote><div><br>The diagram in the docs<br><a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#images">http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#images</a><br>
<br>Clearly show SX maps to DX, SY maps top DY<br><br>But that is not the interpretation that is implemented. The interpretation that is implemented is Source Top/Left maps to Dest Top/Left regardless of whether SX/SY define top left or SX + WIDTH, SY + HEIGHT define top left.<br>
<br>That seems pretty ambiguous to me.<br><br>I'd argue that based on the spec as currently written, all current canvas implementations are wrong. Hence the suggestion to make it unambiguous or get the implementation to match the spec.<br>
<br><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>
<div class="im"><br>
<br>
> I'd like to make a passionate plea that the spec say "implementations<br>
> must support negative widths and negative heights and draw the image<br>
> backward effectively flipping the result".<br>
<br>
</div>If you want to flip the image, use a transform.<br>
<div class="im"><br>
<br>
> Also, I'd like to suggest that a widths and heights of 0 for source<br>
> should be valid as well as rectangles outside of the source also be<br>
> valid and that this part of the spec.<br>
><br>
> "If the source rectangle is not entirely within the source image, or if<br>
> one of the sw or sh arguments is zero, the implementation must raise an<br>
> INDEX_SIZE_ERR exception."<br>
><br>
> be changed to reflect that.<br>
<br>
</div>If height or width is zero, how do you scale the bitmap up to a non-zero<br>
size?<br>
<br>
We could use transparent black for the pixels outside the image, but this<br>
is already interoperably implemented, so I don't want to change it.<br>
<div class="im"><br>
<br>
> Coming from a graphics background I see no reason why if I let my user<br>
> size an image in a canvas I should have to special case a width or<br>
> height of zero. Just draw nothing if the width or height is zero.<br>
> Similarly, if I was to provide a UI to let a user choose part of the<br>
> source to copy to the dest and I let them define a rectangle on the<br>
> source and drag it such that all or part of it is off the source I see<br>
> no reason why I should have to do extra math in my application to make<br>
> that work when simple clipping of values in drawImage would make all<br>
> that extra work required by each app disappear.<br>
<br>
</div>I agree that this may have made sense when the API was being designed a<br>
few years ago.<br>
<div class="im"><br>
<br>
> The next issue related to drawImage is that the spec does not specify<br>
> how to filter an image when scaling it. Should it use bi-linear<br>
> interpolation? Nearest Neighbor? Maybe that should stay implementation<br>
</div>> dependent? On top of that the spec does not say what happens at the<br>
<div class="im">> edges and the different browsers are doing different things. To give you<br>
> an example, if you take a 2x2 pixel image and scale it to 256x256 using<br>
> drawImage. All the major browsers that currently support the canvas tag<br>
> will give you an image where the center of each pixel is around center<br>
> of each 128x128 corner of the 256x256 result. The area inside the area<br>
> defined by those 4 points is rendered very similar on all 4 browsers.<br>
> The area outside though, the edge, is rendered very differently. On<br>
> Safari, Chrome and Opera the colors of the original pixels continue to<br>
> be blended all the way to the edge of the 256x256 area. On Firefox<br>
> though, the blending happens as though the source image was actually 4x4<br>
> pixels instead of 2x2 where the edge pixels are all set to an RGBA value<br>
> of 0, 0, 0, 0. It then draws that scaled image as as though the source<br>
> rectangle was sx = 1, sy = 1, sw = 2, sh = 2 so that you get a<br>
> 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<br>
> give vastly different results.<br>
<br>
</div><div class="im">> Here's a webpage showing the issue.<br>
><br>
> <a href="http://greggman.com/downloads/examples/canvas-test/test-01/canvas-test-01-results.html" target="_blank">http://greggman.com/downloads/examples/canvas-test/test-01/canvas-test-01-results.html</a><br>
<br>
</div>It's not clear to me why what Firefox does is actually wrong. They use<br>
different assumptions, but why is it wrong? There's no trnasparency in the<br>
original, sure, but there's also no pixelation in the original, and no<br>
purple between the two pixels on the left, yet you aren't complaining<br>
about the introduction of pixelation or purple, both of which are done by<br>
one or another of the browsers.<br>
<br>
<br>
On Thu, 9 Jul 2009, Gregg Tavares wrote:<br>
><br>
> [...] Or making it consistent when the DOCTYPE is set to something.<br>
<br>
We're not adding any more quirks modes, four is already far too many. We<br>
want consistency across all modes.<br>
<div class="im"><br>
<br>
> When I scale a rectangular opaque image I expect rectangular opaque<br>
> results. The Firefox implementation does not do this.<br>
<br>
</div>Let them know. This seems like a quality of implementation issue. I don't<br>
expect a 2x2 bitmap with four distinct colours to turn into the washes the<br>
other UAs do either.<br>
<div class="im"><br>
<br>
> If I take a 1x1 pixel image and attempt to use it to cover up something<br>
> in another image by scaling it it will not cover up that other image.<br>
<br>
</div>So don't do that. Use fillRect().<br>
<div class="im"><br>
<br>
On Fri, 10 Jul 2009, Gregg Tavares wrote:<br>
><br>
> I guess I don't understand. I'm new to the list so forgive me but I<br>
> thought HTML5 was still a working draft and that the canvas tag was part<br>
> of that draft. How is a draft immutable?<br>
<br>
</div>Once something gets implemented, it quickly becomes immutable, because<br>
sites start relying on it.<br>
<font color="#888888"><br>
--<br>
Ian Hickson U+1047E )\._.,--....,'``. fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a> U+263A /, _.. \ _\ ;`._ ,.<br>
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'<br>
</font></blockquote></div><br>