Re: [whatwg] Canvas context.drawImage clarification
On Mon, 27 Jul 2009, Gregg Tavares wrote: Could you explain what other interpretations of the following you think are reasonable?: # The source rectangle is the rectangle whose corners are the four points # (sx, sy), (sx+sw, sy), (sx+sw, sy+sh), (sx, sy+sh). # [...] # The destination rectangle is the rectangle whose corners are the four # points (dx, dy), (dx+dw, dy), (dx+dw, dy+dh), (dx, dy+dh). # # When drawImage() is invoked, the region of the image specified by the # source rectangle must be painted on the region of the canvas specified # by the destination rectangle [...] It's ambiguous because images have a direction. An image that starts at 10 with a width of -5 is not the same as an image that starts at 6 with a width of +5 any more than starting in SF and driving 5 miles south is not the same as starting in Brisbane and driving 5 miles north. Huh. I've never considered images as having a direction. I've tried to add text to the spec to make sure that it's clear that no direction is implied here. On Wed, 29 Jul 2009, Gregg Tavares wrote: If it's so clear, why do you think 2 of the 4 browsers that implemented it apparently got it wrong? The browsers only paid passing attention to the spec when implementing it; the spec was being written at the same time. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas context.drawImage clarification
On Tue, Jul 28, 2009 at 4:07 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Tue, Jul 28, 2009 at 1:41 AM, Gregg Tavaresg...@google.com wrote: It's ambiguous because images have a direction. An image that starts at 10 with a width of -5 is not the same as an image that starts at 6 with a width of +5 any more than starting in SF and driving 5 miles south is not the same as starting in Brisbane and driving 5 miles north. The spec doesn't say which interpretation is correct. I think it's extremely clear. The spec gives four points which determine a rectangle, which are in no particular order. The image is rectangular, and is mapped into that rectangle. Rectangles have no orientation, and the operation paint the source region onto the destination region couldn't possibly be interpreted as requiring reorientation of any kind. If it's so clear, why do you think 2 of the 4 browsers that implemented it apparently got it wrong? Would making the spec more explicit have avoided their mis-intepretation? I think you got misled by the diagram, and now aren't reading the normative text of the spec carefully enough -- it's *very* specific (like most of HTML 5).
Re: [whatwg] Canvas context.drawImage clarification
Gregg Tavares wrote: If it's so clear, why do you think 2 of the 4 browsers that implemented it apparently got it wrong? Because the implementations preceded the current spec text; they were just implementing something like Apple's Canvas without trying too hard to be compatible in edge cases. Would making the spec more explicit have avoided their mis-intepretation? Given the above, unlikely. -Boris
Re: [whatwg] Canvas context.drawImage clarification
On Thu, 9 Jul 2009, Gregg Tavares wrote: The specific ambiguity I'd like to bring up has to do with the several versions of a function, context.drawImage. They take width and height values. The spec does not make it clear what is supposed to happen with negative values. My personal interpretation and preference is that negative values should (a) be legal and (b) draw backward, flipping the image. The specification currently says: The source rectangle is the rectangle whose corners are the four points (sx, sy), (sx+sw, sy), (sx+sw, sy+sh), (sx, sy+sh). ... The destination rectangle is the rectangle whose corners are the four points (dx, dy), (dx+dw, dy), (dx+dw, dy+dh), (dx, dy+dh). Well, simple math would suggest that if sx = 10, and sw = -5 then it still defines a valid rectangle. Correct. Why is this ambiguous? The rectangle is well-defined, it just happens that its points are given in a different order than normally. I'd like to make a passionate plea that the spec say implementations must support negative widths and negative heights and draw the image backward effectively flipping the result. If you want to flip the image, use a transform. Also, I'd like to suggest that a widths and heights of 0 for source should be valid as well as rectangles outside of the source also be valid and that this part of the spec. If the source rectangle is not entirely within the source image, or if one of the sw or sh arguments is zero, the implementation must raise an INDEX_SIZE_ERR exception. be changed to reflect that. If height or width is zero, how do you scale the bitmap up to a non-zero size? We could use transparent black for the pixels outside the image, but this is already interoperably implemented, so I don't want to change it. Coming from a graphics background I see no reason why if I let my user size an image in a canvas I should have to special case a width or height of zero. Just draw nothing if the width or height is zero. Similarly, if I was to provide a UI to let a user choose part of the source to copy to the dest and I let them define a rectangle on the source and drag it such that all or part of it is off the source I see no reason why I should have to do extra math in my application to make that work when simple clipping of values in drawImage would make all that extra work required by each app disappear. I agree that this may have made sense when the API was being designed a few years ago. The next issue related to drawImage is that the spec does not specify how to filter an image when scaling it. Should it use bi-linear interpolation? Nearest Neighbor? Maybe that should stay implementation dependent? On top of that the spec does not say what happens at the edges and the different browsers are doing different things. To give you an example, if you take a 2x2 pixel image and scale it to 256x256 using drawImage. All the major browsers that currently support the canvas tag will give you an image where the center of each pixel is around center of each 128x128 corner of the 256x256 result. The area inside the area defined by those 4 points is rendered very similar on all 4 browsers. The area outside though, the edge, is rendered very differently. On Safari, Chrome and Opera the colors of the original pixels continue to be blended all the way to the edge of the 256x256 area. On Firefox though, the blending happens as though the source image was actually 4x4 pixels instead of 2x2 where the edge pixels are all set to an RGBA value of 0, 0, 0, 0. It then draws that scaled image as as though the source rectangle was sx = 1, sy = 1, sw = 2, sh = 2 so that you get a progressively more and more translucent color towards the edge of the rectangle. I don't know which is right but with low resolution source images the 2 give vastly different results. Here's a webpage showing the issue. http://greggman.com/downloads/examples/canvas-test/test-01/canvas-test-01-results.html It's not clear to me why what Firefox does is actually wrong. They use different assumptions, but why is it wrong? There's no trnasparency in the original, sure, but there's also no pixelation in the original, and no purple between the two pixels on the left, yet you aren't complaining about the introduction of pixelation or purple, both of which are done by one or another of the browsers. On Thu, 9 Jul 2009, Gregg Tavares wrote: [...] Or making it consistent when the DOCTYPE is set to something. We're not adding any more quirks modes, four is already far too many. We want consistency across all modes. When I scale a rectangular opaque image I expect rectangular opaque results. The Firefox implementation does not do this. Let them know. This seems like a quality of implementation issue. I don't expect a 2x2 bitmap with four distinct colours to turn into the washes the other UAs do either. If
Re: [whatwg] Canvas context.drawImage clarification
On Mon, Jul 27, 2009 at 3:12 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 9 Jul 2009, Gregg Tavares wrote: The specific ambiguity I'd like to bring up has to do with the several versions of a function, context.drawImage. They take width and height values. The spec does not make it clear what is supposed to happen with negative values. My personal interpretation and preference is that negative values should (a) be legal and (b) draw backward, flipping the image. The specification currently says: The source rectangle is the rectangle whose corners are the four points (sx, sy), (sx+sw, sy), (sx+sw, sy+sh), (sx, sy+sh). ... The destination rectangle is the rectangle whose corners are the four points (dx, dy), (dx+dw, dy), (dx+dw, dy+dh), (dx, dy+dh). Well, simple math would suggest that if sx = 10, and sw = -5 then it still defines a valid rectangle. Correct. Why is this ambiguous? The rectangle is well-defined, it just happens that its points are given in a different order than normally. The diagram in the docs http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#images Clearly show SX maps to DX, SY maps top DY 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. That seems pretty ambiguous to me. 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. I'd like to make a passionate plea that the spec say implementations must support negative widths and negative heights and draw the image backward effectively flipping the result. If you want to flip the image, use a transform. Also, I'd like to suggest that a widths and heights of 0 for source should be valid as well as rectangles outside of the source also be valid and that this part of the spec. If the source rectangle is not entirely within the source image, or if one of the sw or sh arguments is zero, the implementation must raise an INDEX_SIZE_ERR exception. be changed to reflect that. If height or width is zero, how do you scale the bitmap up to a non-zero size? We could use transparent black for the pixels outside the image, but this is already interoperably implemented, so I don't want to change it. Coming from a graphics background I see no reason why if I let my user size an image in a canvas I should have to special case a width or height of zero. Just draw nothing if the width or height is zero. Similarly, if I was to provide a UI to let a user choose part of the source to copy to the dest and I let them define a rectangle on the source and drag it such that all or part of it is off the source I see no reason why I should have to do extra math in my application to make that work when simple clipping of values in drawImage would make all that extra work required by each app disappear. I agree that this may have made sense when the API was being designed a few years ago. The next issue related to drawImage is that the spec does not specify how to filter an image when scaling it. Should it use bi-linear interpolation? Nearest Neighbor? Maybe that should stay implementation dependent? On top of that the spec does not say what happens at the edges and the different browsers are doing different things. To give you an example, if you take a 2x2 pixel image and scale it to 256x256 using drawImage. All the major browsers that currently support the canvas tag will give you an image where the center of each pixel is around center of each 128x128 corner of the 256x256 result. The area inside the area defined by those 4 points is rendered very similar on all 4 browsers. The area outside though, the edge, is rendered very differently. On Safari, Chrome and Opera the colors of the original pixels continue to be blended all the way to the edge of the 256x256 area. On Firefox though, the blending happens as though the source image was actually 4x4 pixels instead of 2x2 where the edge pixels are all set to an RGBA value of 0, 0, 0, 0. It then draws that scaled image as as though the source rectangle was sx = 1, sy = 1, sw = 2, sh = 2 so that you get a progressively more and more translucent color towards the edge of the rectangle. I don't know which is right but with low resolution source images the 2 give vastly different results. Here's a webpage showing the issue. http://greggman.com/downloads/examples/canvas-test/test-01/canvas-test-01-results.html It's not clear to me why what Firefox does is actually wrong. They use different assumptions, but why is it wrong? There's no trnasparency in the original, sure, but there's also no pixelation in the
Re: [whatwg] Canvas context.drawImage clarification
On Mon, 27 Jul 2009, Gregg Tavares wrote: The diagram in the docs http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#images Clearly show SX maps to DX, SY maps top DY 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. That seems pretty ambiguous to me. Ignore the diagram. It's not normative. The text is the only thing that matters. I've moved the diagram up to the intro section to make this clearer. 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. Could you explain what other interpretations of the following you think are reasonable?: # The source rectangle is the rectangle whose corners are the four points # (sx, sy), (sx+sw, sy), (sx+sw, sy+sh), (sx, sy+sh). # [...] # The destination rectangle is the rectangle whose corners are the four # points (dx, dy), (dx+dw, dy), (dx+dw, dy+dh), (dx, dy+dh). # # When drawImage() is invoked, the region of the image specified by the # source rectangle must be painted on the region of the canvas specified # by the destination rectangle [...] It seems pretty unambigious to me. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas context.drawImage clarification
On Mon, Jul 27, 2009 at 4:14 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 27 Jul 2009, Gregg Tavares wrote: The diagram in the docs http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#images Clearly show SX maps to DX, SY maps top DY 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. That seems pretty ambiguous to me. Ignore the diagram. It's not normative. The text is the only thing that matters. I've moved the diagram up to the intro section to make this clearer. 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. Could you explain what other interpretations of the following you think are reasonable?: # The source rectangle is the rectangle whose corners are the four points # (sx, sy), (sx+sw, sy), (sx+sw, sy+sh), (sx, sy+sh). # [...] # The destination rectangle is the rectangle whose corners are the four # points (dx, dy), (dx+dw, dy), (dx+dw, dy+dh), (dx, dy+dh). # # When drawImage() is invoked, the region of the image specified by the # source rectangle must be painted on the region of the canvas specified # by the destination rectangle [...] It's ambiguous because images have a direction. An image that starts at 10 with a width of -5 is not the same as an image that starts at 6 with a width of +5 any more than starting in SF and driving 5 miles south is not the same as starting in Brisbane and driving 5 miles north. The spec doesn't say which interpretation is correct. The one where SrcX maps to DstX and from there width can be positive or negative OR the one as currently implemented in 2 of the 4 browsers which is that Source Left maps to Dest Left regardless of the starting values. Without the diagram, both of those interpretations match the text. With the diagram only 1 interpretation matches, it just happens the be the one no one has implemented. It seems pretty unambigious to me. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas context.drawImage clarification
On Thu, Jul 9, 2009 at 6:25 PM, Oliver Hunt oli...@apple.com wrote: 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. I guess I don't understand. I'm new to the list so forgive me but I thought HTML5 was still a working draft and that the canvas tag was part of that draft. How is a draft immutable? Also, I don't follow the logic here: 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). I don't see how breaking some very small percentage of Webkit sites, or breaking some very small percentage of Gecko/Presto sites is better than from breaking some very small percentage of sites in all of them to make the function useful and the spec specific. (1) The number of sites that use cavnas is exceeding small at this point and the number of those that count on negative width and height behavior being one way or the other is and exceedingly small percent of those (2) breaking some apps is the same as breaking some apps where some #1 is X and some #2 is Y. So what if X Y if both X and Y are less than 0.01% of websites. Consistency and usefulness should win in this case. There is the chance to make the spec unambiguous and more useful before canvas becomes widely used. 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 . I can't claim it's a bug if the spec doesn't define what the correct behavior is. Here's a webpage showing the issue. http://greggman.com/downloads/examples/canvas-test/test-01/canvas-test-01-results.html --Oliver
Re: [whatwg] Canvas context.drawImage clarification
On Jul 10, 2009, at 6:38 PM, Gregg Tavares wrote: On Thu, Jul 9, 2009 at 6:25 PM, Oliver Hunt oli...@apple.com wrote: 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. I guess I don't understand. I'm new to the list so forgive me but I thought HTML5 was still a working draft and that the canvas tag was part of that draft. How is a draft immutable? A reasonable amount of HTML5 is also defining existing behaviour -- Canvas has been shipping in browsers for years now, it was introduced in Safari *2*, so there is actually existing content. ... Consistency and usefulness should win in this case. There is the chance to make the spec unambiguous and more useful before canvas becomes widely used. I'm not arguing that i should not have specified behaviour, i'm merely saying that it needs to specify one of the actually accepted behaviour, it can't introduce a new one. I can't claim it's a bug if the spec doesn't define what the correct behavior is. I can't speak for the gecko canvas implementor, but if this were an issue in webkit i would want a bug so that the behavioural difference was recorded somewhere :D --Oliver
Re: [whatwg] Canvas context.drawImage clarification
I'd like to make a passionate plea that the spec say implementations must support negative widths and negative heights and draw the image backward effectively flipping the result. 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. Also, I'd like to suggest that a widths and heights of 0 for source should be valid as well as rectangles outside of the source also be valid and that this part of the spec. If the source rectangle is not entirely within the source image, or if one of the sw or sh arguments is zero, the implementation must raise an INDEX_SIZE_ERR exception. be changed to reflect that. 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) The next issue related to drawImage is that the spec does not specify how to filter an image when scaling it. Should it use bi-linear interpolation? Nearest Neighbor? Maybe that should stay implementation dependent? Image scaling is implementation dependent everywhere else, why would it be spec defined in the case of canvas? --Oliver
Re: [whatwg] Canvas context.drawImage clarification
On Jul 9, 2009, at 4:19 PM, Gregg Tavares wrote: On Thu, Jul 9, 2009 at 4:11 PM, Oliver Hunt oli...@apple.com wrote: I'd like to make a passionate plea that the spec say implementations must support negative widths and negative heights and draw the image backward effectively flipping the result. 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. 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. 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) 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. 2) How it does the scaling. I agree that it being implementation dependent is probably fine. --Oliver
Re: [whatwg] Canvas context.drawImage clarification
On Thu, Jul 9, 2009 at 4:28 PM, Oliver Hunt oli...@apple.com wrote: On Jul 9, 2009, at 4:19 PM, Gregg Tavares wrote: On Thu, Jul 9, 2009 at 4:11 PM, Oliver Hunt oli...@apple.com wrote: I'd like to make a passionate plea that the spec say implementations must support negative widths and negative heights and draw the image backward effectively flipping the result. 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. 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. 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. 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. 2) How it does the scaling. I agree that it being implementation dependent is probably fine. --Oliver
Re: [whatwg] Canvas context.drawImage clarification
On Jul 9, 2009, at 9:25 PM, Oliver Hunt wrote: I disagree. When I scale a rectangular opaque image I expect rectangular opaque results. The Firefox implementation does not do this. If you believe that to be the case then you can always file a bug at bugs.webkit.org . Why would he file a bug to WebKit for a Firefox rendering issue? I would think that https://bugzilla.mozilla.org/ would get better results. -- Brian Campbell
Re: [whatwg] Canvas context.drawImage clarification
On Jul 9, 2009, at 9:09 PM, Brian Campbell wrote: On Jul 9, 2009, at 9:25 PM, Oliver Hunt wrote: I disagree. When I scale a rectangular opaque image I expect rectangular opaque results. The Firefox implementation does not do this. If you believe that to be the case then you can always file a bug at bugs.webkit.org . Why would he file a bug to WebKit for a Firefox rendering issue? I would think that https://bugzilla.mozilla.org/ would get better results. Whoops, i knew what i meant :D -- Brian Campbell
