Re: [whatwg] createImageData should take unsigned long
On Fri, 04 Sep 2009 02:44:25 +0200, Oliver Hunt oli...@apple.com wrote: On Sep 3, 2009, at 4:50 PM, Robert O'Callahan wrote: On Fri, Sep 4, 2009 at 4:48 AM, Oliver Hunt oli...@apple.com wrote: On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote: Yeah, that seems likely, since none of you implemented the higher-DPI ImageData in your first versions. :-( WebKit's implementation has always worked with high dpi backing stores and follows the spec accordingly. Under what circumstances do you use more than one device pixel per CSS pixel? Does it require the user to turn on UI scaling on Mac? Regardless, I bet that most people using Webkit to write scripts using getImageData still get it wrong, because they have normal screens. Implementing high-res backing store in more browsers won't solve this problem, not until the average developer has a high-dpi screen. But I repeat myself. Indeed -- i was merely commenting that there was actually a correct implementation -- i am still of the opinion that exposing image data was a bad thing and that a filtering API would have been superior. Oh well, the past is the past and we must now live with it. :-/ How can one use this implementation? In my tests getImageData(0,0,w,h) simply returns a wxh ImageData object. It would be interesting to enable this non-1:1 backing store to see if sites break or not. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] createImageData should take unsigned long
On Mon, 31 Aug 2009, Philip J�genstedt wrote: On Mon, 31 Aug 2009 08:08:05 +0200, Ian Hickson i...@hixie.ch wrote: On Mon, 24 Aug 2009, Philip J�genstedt wrote: As far as I can see there's no good reason why createImageData should take a float as input rather than unsigned long. Having it as float creates the odd situation where (0.1, 0.1) gives a 1x1 ImageData while (10.1, 10.1) gives a 10x10 or 11x11 depening on if you ceil or round the input (not defined). Unless there's a compelling reason to allow something like (0.1, 0.1) I suggest changing the type and leaving the float-unsigned conversion to WebIDL. Twenty years from now, when we're using 960dpi screens, 1 CSS pixel might well map to ten device pixels reliably, such that people will want sub-CSS-pixel-level accuracy in their calls to createImageData(). I get the impression this has all been discussed before. Still, it seems unlikely that any browser will ever be able to switch to anything but a 1:1 CSS pixel:device pixel ratio, as that would break all existing pages assuming that getImageData(0, 0, 100, 100) returns a 100x100 bitmap (because assuming that is much easier, unless you read the spec carefully you're unlikely to know it could ever be any different). Yeah, that seems likely, since none of you implemented the higher-DPI ImageData in your first versions. :-( I expect we'll introduce a new API that actually works once there is a browser vendor actually interested in supporting higher-DPI canvases. In any event, judging by existing implementations, the behavior of createImageData(w, h) isn't as clear as it needs to be: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/223 Firefox: log: ctx.createImageData(-1.1,1) = [Exception... log: ctx.createImageData(-1,1) = [Exception... log: ctx.createImageData(-0.1,1) = [Exception... log: ctx.createImageData(0,1) = [Exception... log: ctx.createImageData(0.1,1) = [Exception... log: ctx.createImageData(1,1) = 1x1 log: ctx.createImageData(1.1,1) = 1x1 Safari/Chrome: log: ctx.createImageData(-1.1,1) = 1x1 log: ctx.createImageData(-1,1) = 1x1 log: ctx.createImageData(-0.1,1) = 1x1 log: ctx.createImageData(0,1) = 1x1 log: ctx.createImageData(0.1,1) = 1x1 log: ctx.createImageData(1,1) = 1x1 log: ctx.createImageData(1.1,1) = 2x1 My interpretation of the spec: log: ctx.createImageData(-1.1,1) = 1x1 log: ctx.createImageData(-1,1) = 1x1 log: ctx.createImageData(-0.1,1) = 1x1 log: ctx.createImageData(0,1) = INDEX_SIZE_ERR log: ctx.createImageData(0.1,1) = 1x1 log: ctx.createImageData(1,1) = 1x1 log: ctx.createImageData(1.1,1) = 1x1 The spec doesn't say what size the ImageData objects should be in these cases. Your interpretation is correct insofar as the exception is concerned, though. If the spec doesn't say to round rather than ceil, we're bound to have subtle compatibility bugs on this. The spec says it doesn't matter so long as you're consistent. On Mon, 31 Aug 2009, Robert O'Callahan wrote: Still, it seems unlikely that any browser will ever be able to switch to anything but a 1:1 CSS pixel:device pixel ratio, as that would break all existing pages assuming that getImageData(0, 0, 100, 100) returns a 100x100 bitmap (because assuming that is much easier, unless you read the spec carefully you're unlikely to know it could ever be any different). I agree, but Ian doesn't. It's not so much that I disagree so much as that there is no point fixing this now, since whatever new API we introduce today will just end up broken in the exact some way as the existing API. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] createImageData should take unsigned long
On Thu, 03 Sep 2009 13:54:03 +0200, Ian Hickson i...@hixie.ch wrote: On Mon, 31 Aug 2009, Philip J�genstedt wrote: On Mon, 31 Aug 2009 08:08:05 +0200, Ian Hickson i...@hixie.ch wrote: On Mon, 24 Aug 2009, Philip J�genstedt wrote: As far as I can see there's no good reason why createImageData should take a float as input rather than unsigned long. Having it as float creates the odd situation where (0.1, 0.1) gives a 1x1 ImageData while (10.1, 10.1) gives a 10x10 or 11x11 depening on if you ceil or round the input (not defined). Unless there's a compelling reason to allow something like (0.1, 0.1) I suggest changing the type and leaving the float-unsigned conversion to WebIDL. Twenty years from now, when we're using 960dpi screens, 1 CSS pixel might well map to ten device pixels reliably, such that people will want sub-CSS-pixel-level accuracy in their calls to createImageData(). I get the impression this has all been discussed before. Still, it seems unlikely that any browser will ever be able to switch to anything but a 1:1 CSS pixel:device pixel ratio, as that would break all existing pages assuming that getImageData(0, 0, 100, 100) returns a 100x100 bitmap (because assuming that is much easier, unless you read the spec carefully you're unlikely to know it could ever be any different). Yeah, that seems likely, since none of you implemented the higher-DPI ImageData in your first versions. :-( I expect we'll introduce a new API that actually works once there is a browser vendor actually interested in supporting higher-DPI canvases. I wasn't involved then, but I can only presume that there was no perceived benefit of high-DPI ImageData since you can get high-quality rendering just as well with techniques that don't rely on the canvas being higher resolution than the display device. In any event, judging by existing implementations, the behavior of createImageData(w, h) isn't as clear as it needs to be: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/223 Firefox: log: ctx.createImageData(-1.1,1) = [Exception... log: ctx.createImageData(-1,1) = [Exception... log: ctx.createImageData(-0.1,1) = [Exception... log: ctx.createImageData(0,1) = [Exception... log: ctx.createImageData(0.1,1) = [Exception... log: ctx.createImageData(1,1) = 1x1 log: ctx.createImageData(1.1,1) = 1x1 Safari/Chrome: log: ctx.createImageData(-1.1,1) = 1x1 log: ctx.createImageData(-1,1) = 1x1 log: ctx.createImageData(-0.1,1) = 1x1 log: ctx.createImageData(0,1) = 1x1 log: ctx.createImageData(0.1,1) = 1x1 log: ctx.createImageData(1,1) = 1x1 log: ctx.createImageData(1.1,1) = 2x1 My interpretation of the spec: log: ctx.createImageData(-1.1,1) = 1x1 log: ctx.createImageData(-1,1) = 1x1 log: ctx.createImageData(-0.1,1) = 1x1 log: ctx.createImageData(0,1) = INDEX_SIZE_ERR log: ctx.createImageData(0.1,1) = 1x1 log: ctx.createImageData(1,1) = 1x1 log: ctx.createImageData(1.1,1) = 1x1 The spec doesn't say what size the ImageData objects should be in these cases. Your interpretation is correct insofar as the exception is concerned, though. If the spec doesn't say to round rather than ceil, we're bound to have subtle compatibility bugs on this. The spec says it doesn't matter so long as you're consistent. On Mon, 31 Aug 2009, Robert O'Callahan wrote: Still, it seems unlikely that any browser will ever be able to switch to anything but a 1:1 CSS pixel:device pixel ratio, as that would break all existing pages assuming that getImageData(0, 0, 100, 100) returns a 100x100 bitmap (because assuming that is much easier, unless you read the spec carefully you're unlikely to know it could ever be any different). I agree, but Ian doesn't. It's not so much that I disagree so much as that there is no point fixing this now, since whatever new API we introduce today will just end up broken in the exact some way as the existing API. The fix is not to introduce a new API that can handle high-DPI ImageData, but rather to make the spec reflect the reality that high-DPI ImageData implementations won't be possible with this version of the API. That would include, among other things, specifying that getImageData(0, 0, w, h) returns a wxh ImageData object, removing createImageData(ImageData) and making createImageData(w, h) take unsigned long and return a wxh ImageData object. In other words, aligning with what implementations already do (and will continue to do for compatibility reasons). -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] createImageData should take unsigned long
Philip Jägenstedt wrote: I wasn't involved then, but I can only presume that there was no perceived benefit of high-DPI ImageData since you can get high-quality rendering just as well with techniques that don't rely on the canvas being higher resolution than the display device. To be clear, in this context high-DPI means using the DPI of the display device, instead of the about 96dpi you get with CSS pixels. So if this were done and I have a 300-dpi screen, there would be, say, 3 imagedata pixels per CSS pixel. If you have a 200-dpi screen, then on our computer there would be 2 imagedata pixels per CSS pixel. Script would have to be able to deal with this, which is where the APIs like createImageData(imageData) come in. -Boris
Re: [whatwg] createImageData should take unsigned long
On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote: Yeah, that seems likely, since none of you implemented the higher-DPI ImageData in your first versions. :-( WebKit's implementation has always worked with high dpi backing stores and follows the spec accordingly. --Oliver
Re: [whatwg] createImageData should take unsigned long
On Fri, Sep 4, 2009 at 4:48 AM, Oliver Hunt oli...@apple.com wrote: On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote: Yeah, that seems likely, since none of you implemented the higher-DPI ImageData in your first versions. :-( WebKit's implementation has always worked with high dpi backing stores and follows the spec accordingly. Under what circumstances do you use more than one device pixel per CSS pixel? Does it require the user to turn on UI scaling on Mac? Regardless, I bet that most people using Webkit to write scripts using getImageData still get it wrong, because they have normal screens. Implementing high-res backing store in more browsers won't solve this problem, not until the average developer has a high-dpi screen. But I repeat myself. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] createImageData should take unsigned long
On Sep 3, 2009, at 4:50 PM, Robert O'Callahan wrote: On Fri, Sep 4, 2009 at 4:48 AM, Oliver Hunt oli...@apple.com wrote: On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote: Yeah, that seems likely, since none of you implemented the higher-DPI ImageData in your first versions. :-( WebKit's implementation has always worked with high dpi backing stores and follows the spec accordingly. Under what circumstances do you use more than one device pixel per CSS pixel? Does it require the user to turn on UI scaling on Mac? Regardless, I bet that most people using Webkit to write scripts using getImageData still get it wrong, because they have normal screens. Implementing high-res backing store in more browsers won't solve this problem, not until the average developer has a high-dpi screen. But I repeat myself. Indeed -- i was merely commenting that there was actually a correct implementation -- i am still of the opinion that exposing image data was a bad thing and that a filtering API would have been superior. Oh well, the past is the past and we must now live with it. :-/ --Oliver
Re: [whatwg] createImageData should take unsigned long
On Mon, 24 Aug 2009, Philip Jägenstedt wrote: As far as I can see there's no good reason why createImageData should take a float as input rather than unsigned long. Having it as float creates the odd situation where (0.1, 0.1) gives a 1x1 ImageData while (10.1, 10.1) gives a 10x10 or 11x11 depening on if you ceil or round the input (not defined). Unless there's a compelling reason to allow something like (0.1, 0.1) I suggest changing the type and leaving the float-unsigned conversion to WebIDL. Twenty years from now, when we're using 960dpi screens, 1 CSS pixel might well map to ten device pixels reliably, such that people will want sub-CSS-pixel-level accuracy in their calls to createImageData(). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] createImageData should take unsigned long
On Mon, 31 Aug 2009 08:08:05 +0200, Ian Hickson i...@hixie.ch wrote: On Mon, 24 Aug 2009, Philip Jägenstedt wrote: As far as I can see there's no good reason why createImageData should take a float as input rather than unsigned long. Having it as float creates the odd situation where (0.1, 0.1) gives a 1x1 ImageData while (10.1, 10.1) gives a 10x10 or 11x11 depening on if you ceil or round the input (not defined). Unless there's a compelling reason to allow something like (0.1, 0.1) I suggest changing the type and leaving the float-unsigned conversion to WebIDL. Twenty years from now, when we're using 960dpi screens, 1 CSS pixel might well map to ten device pixels reliably, such that people will want sub-CSS-pixel-level accuracy in their calls to createImageData(). I get the impression this has all been discussed before. Still, it seems unlikely that any browser will ever be able to switch to anything but a 1:1 CSS pixel:device pixel ratio, as that would break all existing pages assuming that getImageData(0, 0, 100, 100) returns a 100x100 bitmap (because assuming that is much easier, unless you read the spec carefully you're unlikely to know it could ever be any different). I don't doubt that high DPI screens will happen, but when it does browsers are more likely to provide an extra flag like getImageData(..., useDevicePixels) or another opt-in method in order to stay compatible with existing content. Another option for the page author is simply creating a 1000x1000 canvas and setting its CSS width/height to 100x100 (assuming the CSS pixel:device pixel ratio can be found via script). In any event, judging by existing implementations, the behavior of createImageData(w, h) isn't as clear as it needs to be: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/223 Firefox: log: ctx.createImageData(-1.1,1) = [Exception... log: ctx.createImageData(-1,1) = [Exception... log: ctx.createImageData(-0.1,1) = [Exception... log: ctx.createImageData(0,1) = [Exception... log: ctx.createImageData(0.1,1) = [Exception... log: ctx.createImageData(1,1) = 1x1 log: ctx.createImageData(1.1,1) = 1x1 Safari/Chrome: log: ctx.createImageData(-1.1,1) = 1x1 log: ctx.createImageData(-1,1) = 1x1 log: ctx.createImageData(-0.1,1) = 1x1 log: ctx.createImageData(0,1) = 1x1 log: ctx.createImageData(0.1,1) = 1x1 log: ctx.createImageData(1,1) = 1x1 log: ctx.createImageData(1.1,1) = 2x1 My interpretation of the spec: log: ctx.createImageData(-1.1,1) = 1x1 log: ctx.createImageData(-1,1) = 1x1 log: ctx.createImageData(-0.1,1) = 1x1 log: ctx.createImageData(0,1) = INDEX_SIZE_ERR log: ctx.createImageData(0.1,1) = 1x1 log: ctx.createImageData(1,1) = 1x1 log: ctx.createImageData(1.1,1) = 1x1 If the spec doesn't say to round rather than ceil, we're bound to have subtle compatibility bugs on this. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] createImageData should take unsigned long
On Mon, Aug 31, 2009 at 1:55 AM, Philip Jägenstedt phil...@opera.comwrote: I get the impression this has all been discussed before. It has. Still, it seems unlikely that any browser will ever be able to switch to anything but a 1:1 CSS pixel:device pixel ratio, as that would break all existing pages assuming that getImageData(0, 0, 100, 100) returns a 100x100 bitmap (because assuming that is much easier, unless you read the spec carefully you're unlikely to know it could ever be any different). I agree, but Ian doesn't. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] createImageData should take unsigned long
Philip Jägenstedt wrote: In any event, judging by existing implementations, the behavior of createImageData(w, h) isn't as clear as it needs to be: Firefox: Just to be clear, the Firefox code for this predates the spec text. I would assume so does Webkit's. Once we're actually trying to implement the spec, we'll probably comment if we think it makes no sense or isn't clear... ;) -Boris
Re: [whatwg] createImageData should take unsigned long
On Mon, Aug 31, 2009 at 11:06 PM, Anne van Kesteren ann...@opera.comwrote: Once we get huge screens and lots of processing power people can just blow up the canvas grid and then scale it down with CSS. Works just as well and makes the data more portable. I think we can do better than that. It's fine to use high-dpi backing store automatically for canvas in general. ImageData is the only situation where it matters if there's more than one device pixel per CSS pixel, and authors should be able to opt into taking advantage of that fact, but not be exposed to it by default, IMHO. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
