Re: [whatwg] getImageData/putImageData comments
On Fri, 10 Jul 2009, Boris Zbarsky wrote: Ian Hickson wrote: I don't see why the imagedata API isn't suitable for that. It's not like if you're painting that on the canvas you'll want to leave the last row or column unaffected. You'll want to clear it or some such, in practice. I believe in this case the page actually wants to create a canvas for each intermediate state, so needs to create canvases sized 1 imagedata pixel smaller than a given canvas Just painting to a canvas of the old size isn't right, since it'll then take too much space in the layout. That seems like an unnecessarily complicated way of doing things. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getImageData/putImageData comments
On Fri, 12 Jun 2009, Boris Zbarsky wrote: Ian Hickson wrote: 2) The description of putImageData says it Paints the data from the given ImageData object onto the canvas. It may be worth specifying that this uses the SOURCE operator, though this is clear later on when defining what the method _really_ does. That's the author description, which is non-normative and trades precision for accessibility, so I've not added this text. I recommend not reading those sections as an implementor. I was reading it as an author; as an author I assumed that if I'm painting data with an alpha 1 I'll see things under it (which is not hthe case with PutImageData). Ah, ok. Fixed. The long and short of this is that if we solve this problem today, the solution will be abused as much as the current API, and we'll have to introduce yet another solution when high-res backing stores are common. So instead I'm hoping that (a) authors won't screw this up, and (b) high-res backing stores will be implemented sooner rather than later. If we fail with (a), which is more likely if (b) is delayed, then we'll just introduce a higher-res API later, and designate this one a lost cause. OK. This was sort of discussed in a follow-on thread to my mail, but my last comment about there being two fundamentally different use cases for PutImageData never got any responses... [...] It was the first use I tried to put canvas to: visualizing something by computing color values for pixels and then painting to the canvas (in my case Julia sets). Yeah, I guess if you want to generate low-res bitmap data using an array-like API, the current canvas doesn't really help you. The putImageData() API is really intended for filters and generated patterns, both of which would want to be as high-res as possible. People are using it for things that are not filters or generated patterns as we speak... And generally getting it wrong (in the sense that their stuff will break on high-res displays). Not much we can do about that yet. On Sat, 13 Jun 2009, Boris Zbarsky wrote: It's not that hard, it's an extra four or five lines of code to fill in multiple pixels in a square (two nested for-loops and an expression or two to work out what the limit is). Compared to the maths such code would be doing anyway, this is trivial stuff. The hard part is realizing you have to do it... And in particular, the fact that it's not just filling in multiple pixels in a square... For another example, consider an algorithm that wants to reduce the size of the image by 1px horizontally (e.g. content-aware image resizing as demoed using canvas at http://labs.pimsworld.org/wp-content/uploads/2009/04/demo-content-aware-image-resizing-2/). If we're shrinking by one device pixel, then suddenly we can't even create a canvas of the right size for the new image, because canvas size is specified in integer CSS pixels. Note that the algorithm used here, basically off-the-shelf, would in fact want to work on device pixels the way the spec is written right now; in general it would want to work on whatever pixels imagedata is in. If you want to shrink an image, redraw it using drawImage() with different dimensions. If we want to shrink by one CSS pixel, so we can actually draw the canvas, then each shrink step needs to apply the algorithm N times, right? But what if N is, say, 2.5, as it can be in Safari? It's been pointed out before that 1 css pixel can map to a fractional number of device pixels there... That algorithm can't very well be applied 2.5 times. Of course my Julia set example would also need to do something a lot more interesting than just fill in multiple pixels in a square when the css-to-device pixel ratio is non-integral. Note that I don't have a proposed solution here; I'm just pointing out that the authoring pitfalls here are a lot more complicated than you seem to give them credit for. Yeah, I can see that there are cases that are a lot more complex than it would first seem. I don't know what we can do about it either, though. On Sat, 13 Jun 2009, Robert O'Callahan wrote: On Sat, Jun 13, 2009 at 6:57 PM, Ian Hickson i...@hixie.ch wrote: There's no practical difference as far as I can tell between hoping that we can reuse the API, and then finding we can't, and introducing a second API for high-res screens; and just giving up now and saying that it's a low-res API, and then adding a second API later when we have high-res screens. The effect is more or less the same. Given that, I think it's worth at least trying to see if we get away with it and can in fact use this API in high-res situations later. The difference to me as an implementor is that as the spec stands, I have to choose between 1) Implement high-resolution canvas backing store and implementing image data per spec, breaking most of
Re: [whatwg] getImageData/putImageData comments
Ian Hickson wrote: For another example, consider an algorithm that wants to reduce the size of the image by 1px horizontally (e.g. content-aware image resizing as demoed using canvas at http://labs.pimsworld.org/wp-content/uploads/2009/04/demo-content-aware-image-resizing-2/). If we're shrinking by one device pixel, then suddenly we can't even create a canvas of the right size for the new image, because canvas size is specified in integer CSS pixels. Note that the algorithm used here, basically off-the-shelf, would in fact want to work on device pixels the way the spec is written right now; in general it would want to work on whatever pixels imagedata is in. If you want to shrink an image, redraw it using drawImage() with different dimensions. You apparently didn't look at the linked-to page. It's basically applying a graphical filter to an image that results in a smaller image. It's explicitly NOT trying to resize the image using whatever algorithm the browser happens to implement; it's implementing its own image-resizing algorithm (one that arguably produces much better results at the cost of a lot more computation). I don't know what we can do about it either, though. I'll think about this some more... I'm not too hopeful, though. :( Especially for that image-resizing case, where we basically need to be able to create a canvas with fractional CSS pixel dimensions or something. -Boris
Re: [whatwg] getImageData/putImageData comments
On Fri, 10 Jul 2009, Boris Zbarsky wrote: Ian Hickson wrote: For another example, consider an algorithm that wants to reduce the size of the image by 1px horizontally (e.g. content-aware image resizing as demoed using canvas at http://labs.pimsworld.org/wp-content/uploads/2009/04/demo-content-aware-image-resizing-2/). If we're shrinking by one device pixel, then suddenly we can't even create a canvas of the right size for the new image, because canvas size is specified in integer CSS pixels. Note that the algorithm used here, basically off-the-shelf, would in fact want to work on device pixels the way the spec is written right now; in general it would want to work on whatever pixels imagedata is in. If you want to shrink an image, redraw it using drawImage() with different dimensions. You apparently didn't look at the linked-to page. It's basically applying a graphical filter to an image that results in a smaller image. It's explicitly NOT trying to resize the image using whatever algorithm the browser happens to implement; it's implementing its own image-resizing algorithm (one that arguably produces much better results at the cost of a lot more computation). Hm, neat. I don't see why the imagedata API isn't suitable for that. It's not like if you're painting that on the canvas you'll want to leave the last row or column unaffected. You'll want to clear it or some such, in practice. I think this use case works fine with the current API. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getImageData/putImageData comments
Ian Hickson wrote: I don't see why the imagedata API isn't suitable for that. It's not like if you're painting that on the canvas you'll want to leave the last row or column unaffected. You'll want to clear it or some such, in practice. I believe in this case the page actually wants to create a canvas for each intermediate state, so needs to create canvases sized 1 imagedata pixel smaller than a given canvas Just painting to a canvas of the old size isn't right, since it'll then take too much space in the layout. -Boris
Re: [whatwg] getImageData/putImageData comments
On Sat, Jun 13, 2009 at 6:39 AM, Ian Hickson i...@hixie.ch wrote: The long and short of this is that if we solve this problem today, the solution will be abused as much as the current API, and we'll have to introduce yet another solution when high-res backing stores are common. So instead I'm hoping that (a) authors won't screw this up, and (b) high-res backing stores will be implemented sooner rather than later. If we fail with (a), which is more likely if (b) is delayed, then we'll just introduce a higher-res API later, and designate this one a lost cause. Whether high-resolution backing stores are implemented or not is irrelevant as long as most authors are testing their scripts on systems configured with a 1:1 ratio of CSS pixels to device pixels. So in practice you're also relying on (c) rapid deployment of high-dpi screens to canvas-using Web developers. That's why I think you hope in vain. Altering the current API so that it always uses one image-data pixel per CSS pixel would not make it useless. Everything people are currently using it for will continue to work just fine and the visual results will be just as good as what people are currently seeing. It's just that we'll need a new API in the future to take maximum advantage of hardware. 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] getImageData/putImageData comments
On Sat, 13 Jun 2009, Robert O'Callahan wrote: On Sat, Jun 13, 2009 at 6:39 AM, Ian Hickson i...@hixie.ch wrote: The long and short of this is that if we solve this problem today, the solution will be abused as much as the current API, and we'll have to introduce yet another solution when high-res backing stores are common. So instead I'm hoping that (a) authors won't screw this up, and (b) high-res backing stores will be implemented sooner rather than later. If we fail with (a), which is more likely if (b) is delayed, then we'll just introduce a higher-res API later, and designate this one a lost cause. Whether high-resolution backing stores are implemented or not is irrelevant as long as most authors are testing their scripts on systems configured with a 1:1 ratio of CSS pixels to device pixels. So in practice you're also relying on (c) rapid deployment of high-dpi screens to canvas-using Web developers. That's why I think you hope in vain. Altering the current API so that it always uses one image-data pixel per CSS pixel would not make it useless. Everything people are currently using it for will continue to work just fine and the visual results will be just as good as what people are currently seeing. It's just that we'll need a new API in the future to take maximum advantage of hardware. Right, but that would be less optimal than if we could just re-use today's API, hence the hope. There's no practical difference as far as I can tell between hoping that we can reuse the API, and then finding we can't, and introducing a second API for high-res screens; and just giving up now and saying that it's a low-res API, and then adding a second API later when we have high-res screens. The effect is more or less the same. Given that, I think it's worth at least trying to see if we get away with it and can in fact use this API in high-res situations later. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getImageData/putImageData comments
On Sat, Jun 13, 2009 at 6:57 PM, Ian Hickson i...@hixie.ch wrote: There's no practical difference as far as I can tell between hoping that we can reuse the API, and then finding we can't, and introducing a second API for high-res screens; and just giving up now and saying that it's a low-res API, and then adding a second API later when we have high-res screens. The effect is more or less the same. Given that, I think it's worth at least trying to see if we get away with it and can in fact use this API in high-res situations later. The difference to me as an implementor is that as the spec stands, I have to choose between 1) Implement high-resolution canvas backing store and implementing image data per spec, breaking most of the current scripts that are using image-data for all the users who can actually take advantage of that high-resolution backing store 2) Implement high-resolution canvas backing store and quietly violate the spec so that the current generation of image-data-using scripts continue to work 3) Don't implement high-resolution backing store, which at least means I don't have to choose between violating the spec and breaking content 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] getImageData/putImageData comments
Boris Zbarsky wrote: It's not that hard, it's an extra four or five lines of code to fill in multiple pixels in a square (two nested for-loops and an expression or two to work out what the limit is). Compared to the maths such code would be doing anyway, this is trivial stuff. The hard part is realizing you have to do it... And in particular, the fact that it's not just filling in multiple pixels in a square... For another example, consider an algorithm that wants to reduce the size of the image by 1px horizontally (e.g. content-aware image resizing as demoed using canvas at http://labs.pimsworld.org/wp-content/uploads/2009/04/demo-content-aware-image-resizing-2/). If we're shrinking by one device pixel, then suddenly we can't even create a canvas of the right size for the new image, because canvas size is specified in integer CSS pixels. Note that the algorithm used here, basically off-the-shelf, would in fact want to work on device pixels the way the spec is written right now; in general it would want to work on whatever pixels imagedata is in. If we want to shrink by one CSS pixel, so we can actually draw the canvas, then each shrink step needs to apply the algorithm N times, right? But what if N is, say, 2.5, as it can be in Safari? It's been pointed out before that 1 css pixel can map to a fractional number of device pixels there... That algorithm can't very well be applied 2.5 times. Of course my Julia set example would also need to do something a lot more interesting than just fill in multiple pixels in a square when the css-to-device pixel ratio is non-integral. Note that I don't have a proposed solution here; I'm just pointing out that the authoring pitfalls here are a lot more complicated than you seem to give them credit for. -Boris
Re: [whatwg] getImageData/putImageData comments
On Mon, 1 Jun 2009, Boris Zbarsky wrote: I still think that we need a better I have some externally-derived pixel data I'd like to just stick in this canvas API here. fillRect() has terrible performance characteristics (as has been brought up many times before), and the current imagedata design makes it very difficult to use it correctly for this purpose... It's not that hard, it's an extra four or five lines of code to fill in multiple pixels in a square (two nested for-loops and an expression or two to work out what the limit is). Compared to the maths such code would be doing anyway, this is trivial stuff. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getImageData/putImageData comments
Ian Hickson wrote: 2) The description of putImageData says it Paints the data from the given ImageData object onto the canvas. It may be worth specifying that this uses the SOURCE operator, though this is clear later on when defining what the method _really_ does. That's the author description, which is non-normative and trades precision for accessibility, so I've not added this text. I recommend not reading those sections as an implementor. I was reading it as an author; as an author I assumed that if I'm painting data with an alpha 1 I'll see things under it (which is not hthe case with PutImageData). The long and short of this is that if we solve this problem today, the solution will be abused as much as the current API, and we'll have to introduce yet another solution when high-res backing stores are common. So instead I'm hoping that (a) authors won't screw this up, and (b) high-res backing stores will be implemented sooner rather than later. If we fail with (a), which is more likely if (b) is delayed, then we'll just introduce a higher-res API later, and designate this one a lost cause. OK. This was sort of discussed in a follow-on thread to my mail, but my last comment about there being two fundamentally different use cases for PutImageData never got any responses Also, I'm not really convinced that the use case you describe is common. It was the first use I tried to put canvas to: visualizing something by computing color values for pixels and then painting to the canvas (in my case Julia sets). If you have sprite data, use drawImage(). I don't. The putImageData() API is really intended for filters and generated patterns, both of which would want to be as high-res as possible. People are using it for things that are not filters or generated patterns as we speak... And generally getting it wrong (in the sense that their stuff will break on high-res displays). -Boris
Re: [whatwg] getImageData/putImageData comments
Ian Hickson wrote: On Mon, 1 Jun 2009, Boris Zbarsky wrote: I still think that we need a better I have some externally-derived pixel data I'd like to just stick in this canvas API here. fillRect() has terrible performance characteristics (as has been brought up many times before), and the current imagedata design makes it very difficult to use it correctly for this purpose... It's not that hard, it's an extra four or five lines of code to fill in multiple pixels in a square (two nested for-loops and an expression or two to work out what the limit is). Compared to the maths such code would be doing anyway, this is trivial stuff. The hard part is realizing you have to do it... -Boris
Re: [whatwg] getImageData/putImageData comments
On May 31, 2009, at 6:55 PM, Boris Zbarsky wrote: 3) It's not clear to me why imagedata actually exposes device pixels, nor is it clear to me how this is supposed to work if the same document is being rendered to multiple devices. Is a UA allowed to have a higher internal resolution for a canvas (in device pixels) and then sample when painting to the device? This might well be desirable if the UA expects the canvas to be scaled; it can well reduce scaling artifacts in that situation. It doesn't seem reasonable, to me, to expose such super-sampling via imageData; it's entirely an optimization detail. Worse yet, the current setup means that a script that tries createImageData, fill in the pixels, and then paint it to the canvas, needs to fill different numbers of pixels depending on the output device. I fully expect script authors to get this very very wrong, since it's such non-intuitive behavior. It would make more sense to just have the script work entirely in CSS pixels; if it wishes to create a higher-resolution image it can create a canvas with bigger dimensions (and scale its actual display via setting its width and height CSS properties). In some environments, a CSS pixel may be more than one device pixel. In this case, getImageData followed by putImageData will lose resolution. In other cases, a CSS pixel may be a non-integer number of device pixels. To see an example of a browser running in this environment, on Mac OS X launch Quartz Debug, open the User Interface Resolution window, and try setting the scale factor to 1.5 or 2.0. In this case in Safari, the CSS px unit will respect the scale factor, but the canvas backing store will still be in device pixels so users get the benefit of the higher resolution. (Currently Apple doesn't ship any systems that use a non-1.0 UI scale factor by default.) The current design makes it possible to write code that will do the right thing in a scaled UI. It also makes it easy to do the wrong thing and copy only a fraction of the area intended. The alternate design of using CSS pixels would make it impossible to get right, but the failure mode would just be to lose resolution. Regards, Maciej
Re: [whatwg] getImageData/putImageData comments
On May 31, 2009, at 9:08 PM, Robert O'Callahan wrote: Here are a couple of relevant threads: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011284.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013906.html Then there was a discussion on #whatwg more recently. http://krijnhoetmer.nl/irc-logs/whatwg/20090326#l-263 So far it seems the data supports the hypothesis that authors expect getImageData to return 1 image pixel per CSS pixel and their scripts break when that's not true. That won't change until authors all have high-dpi screens. I'm not surprised. On the other hand, if we use CSS pixels, it won't be possible for authors to get it right, even if they do have high-dpi screens. It might be wise to have separate APIs (or a distinguishing parameter) to indicate whether you want scaled or true resolution. That way, unaware code gets a resolution loss, but aware code can do the right thing. I guess you suggested something like that in the IRC conversation you cited. Regards, Maciej
Re: [whatwg] getImageData/putImageData comments
On Mon, Jun 1, 2009 at 7:13 PM, Maciej Stachowiak m...@apple.com wrote: On May 31, 2009, at 9:08 PM, Robert O'Callahan wrote: Here are a couple of relevant threads: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011284.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013906.html Then there was a discussion on #whatwg more recently. http://krijnhoetmer.nl/irc-logs/whatwg/20090326#l-263 So far it seems the data supports the hypothesis that authors expect getImageData to return 1 image pixel per CSS pixel and their scripts break when that's not true. That won't change until authors all have high-dpi screens. I'm not surprised. On the other hand, if we use CSS pixels, it won't be possible for authors to get it right, even if they do have high-dpi screens. It might be wise to have separate APIs (or a distinguishing parameter) to indicate whether you want scaled or true resolution. That way, unaware code gets a resolution loss, but aware code can do the right thing. I guess you suggested something like that in the IRC conversation you cited. Yes. Why don't we just redefine getImageData right now to have the behaviour authors are depending on, since we will likely be forced into that anyway? I'm not sure whether we should define the new API right now (getHighResolutionImageData?), or wait until CSS-to-device-pixel-ratios != 1 are common enough that authors are likely to use the new API correctly. 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] getImageData/putImageData comments
Maciej Stachowiak wrote: In some environments, a CSS pixel may be more than one device pixel. Yes, I'm well aware. In this case, getImageData followed by putImageData will lose resolution. Right. I did mention that in my reply to Oliver. It seems that there are two significantly different use cases for putImageData. One is that of doing getImageData on a canvas followed by some manipulation of the existing pixel data. In this case I agree that: The current design makes it possible to write code that will do the right thing in a scaled UI. It also makes it easy to do the wrong thing and copy only a fraction of the area intended. I'm not quite sure what I think of the tradeoffs here yet, and I need to go read through the old discussions, but I do appreciate the problems. The other use case is doing createImageData, followed by filling in the pixels, followed by putImageData. In this case, there is no quality loss of existing data involved, but the current design still makes it easy to do the wrong thing... In fact, it makes it much more difficult than it should be to do the right thing for a typical web developer. Perhaps the two use cases should use a different put API and incompatible imagedata objects and actually use different coordinate spaces? It'd be somewhat confusing, but the use cases for the two seem to me to be sufficiently different that it might be warranted... -Boris
Re: [whatwg] getImageData/putImageData comments
Boris Zbarsky wrote: The other use case is doing createImageData, followed by filling in the pixels, followed by putImageData. I just saw the example in the spec that does just this, but bases the values it puts in on numbers it gets out of getImageData. For that case you would of course want a blank imagedata that matches what getImageData hands out. I still think that we need a better I have some externally-derived pixel data I'd like to just stick in this canvas API here. fillRect() has terrible performance characteristics (as has been brought up many times before), and the current imagedata design makes it very difficult to use it correctly for this purpose... -Boris
Re: [whatwg] getImageData/putImageData comments
Worse yet, the current setup means that a script that tries createImageData, fill in the pixels, and then paint it to the canvas, needs to fill different numbers of pixels depending on the output device. I fully expect script authors to get this very very wrong, since it's such non-intuitive behavior. It would make more sense to just have the script work entirely in CSS pixels; if it wishes to create a higher-resolution image it can create a canvas with bigger dimensions (and scale its actual display via setting its width and height CSS properties). This has been discussed heavily before. It was always intended that canvas be resolution independent in a given environment. Requiring a developer to do this is nonsensical as the developer has no way to know what they should be doing. eg. why should drawing an arc in a canvas produce aliased output yet drawing an arc in svg not when they're both being drawn at the same time on the same device? or why should text drawn to the canvas look fuzzy compared to the text drawn next to it outside of the canvas? This is basically what you are asking for. --Oliver
Re: [whatwg] getImageData/putImageData comments
Oliver Hunt wrote: Worse yet, the current setup means that a script that tries createImageData, fill in the pixels, and then paint it to the canvas, needs to fill different numbers of pixels depending on the output device. I fully expect script authors to get this very very wrong, since it's such non-intuitive behavior. It would make more sense to just have the script work entirely in CSS pixels; if it wishes to create a higher-resolution image it can create a canvas with bigger dimensions (and scale its actual display via setting its width and height CSS properties). This has been discussed heavily before. Pointer, please. It was always intended that canvas be resolution independent in a given environment. That's fine; I have no problem with that. Requiring a developer to do this is nonsensical as the developer has no way to know what they should be doing. Precisely my point above. eg. why should drawing an arc in a canvas produce aliased output yet drawing an arc in svg not when they're both being drawn at the same time on the same device? It shouldn't, if you're drawing the arc via the vector canvas API... except for the little issue that canvas is fundamentally a bitmap and you get to set up how big the bitmap is (via its width and height properties). That's more or less by design: canvas is meant to be an editable bitmap image. We can argue about whether such a thing is desirable, of course. or why should text drawn to the canvas look fuzzy compared to the text drawn next to it outside of the canvas? This is basically what you are asking for. Not at all. What I am asking for is that if you getImageData you get CSS pixels, so that you don't end up with device-dependent behavior of getImageData. Similarly, I'm asking that the pixels in putImageData be treated as CSS pixels, so that you don't have to write device-dependent code for filling in the imageData before putting it. This has no effect on text drawing or arc drawing; those would happen at whatever resolution the UA decides to use for the canvas' backing store (which may well be significantly higher than the resolution of the device the canvas is going to be painted to, precisely because the UA wants things to remain non-fuzzy even if the canvas is scaled). Let's take a concrete example. I'd like to use canvas to draw Julia sets. I specify a 500x500 size for the canvas (via width and height) and plan to use it to represent a rectangle in the complex plane that satisfies |Re(z)| 250 and |Im(z)| 250. This 500x500 size is in CSS pixels. The UA allocates some sort of backing store for it (maybe it's 500x500, maybe it's 2000x2000; that's the UA's business and might depend on the device). So far everything is the same both in the spec as it stands now and in what I think it should say. Now I start actually computing my pixel color values. I iterate over my values of Z, compute the color for each value... then what do I put in the imageData? With the spec as written it depends on the precise backing store setup, because I am trying to actually color in the logical pixels of the canvas. If imageData used CSS pixels, I just put each of my computed color values into one pixel of the imageData. That might be more than one pixel in the UA's backing store, but that's not a problem: I'm doing raw bitmap access, and hence would expect the bitmap to alias if zoomed in. -Boris P.S. Either I totally misunderstood your reply, or you totally misunderstood my original proposal. I'd like to know which. P.P.S. If the point is that one might want to draw some arcs+text, then getImageData to get the backing store, then do some sort of processing on it, then put it back and not lose quality, then it sounds like we need two different image data APIs: one that works on backing store pixels for such processing, and one that works on CSS pixels for actually painting to the canvas. P.P.P.S. Yes, I know it's possible to use fillRect() to get the effect I want for Julia sets. It's a lot slower (2-40x, depending on how hard you try to work around the slowness and which browser you're using and exactly what your pixels look like) than using imageData.
Re: [whatwg] getImageData/putImageData comments
On Mon, Jun 1, 2009 at 3:47 PM, Boris Zbarsky bzbar...@mit.edu wrote: Oliver Hunt wrote: Worse yet, the current setup means that a script that tries createImageData, fill in the pixels, and then paint it to the canvas, needs to fill different numbers of pixels depending on the output device. I fully expect script authors to get this very very wrong, since it's such non-intuitive behavior. It would make more sense to just have the script work entirely in CSS pixels; if it wishes to create a higher-resolution image it can create a canvas with bigger dimensions (and scale its actual display via setting its width and height CSS properties). This has been discussed heavily before. Pointer, please. Here are a couple of relevant threads: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011284.html http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-February/013906.html Then there was a discussion on #whatwg more recently. http://krijnhoetmer.nl/irc-logs/whatwg/20090326#l-263 So far it seems the data supports the hypothesis that authors expect getImageData to return 1 image pixel per CSS pixel and their scripts break when that's not true. That won't change until authors all have high-dpi screens. Actually I thought I'd won Ollie over on this: http://krijnhoetmer.nl/irc-logs/whatwg/20090326#l-367 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]
