[whatwg] More random comments on the putImageData definition

[Oliver Hunt]

On Feb 10, 2008, at 2:53 PM, Robert O'Callahan wrote:

> On Feb 11, 2008 11:37 AM, Oliver Hunt <oliver at apple.com> wrote:
>
> On Feb 10, 2008, at 2:26 PM, Robert O'Callahan wrote:
>> On Feb 10, 2008 10:07 PM, Oliver Hunt <oliver at apple.com> wrote:
>> That said, basically what you're saying is that canvas should not  
>> support hidpi.  At all. There is no need to request the dpi of a  
>> canvas, but (and here's the critical bit) you can't have get/ 
>> putImageData work at a different resolution from the backing buffer.
>>
>> Why not?
> Because the purpose of get/putImageData *is* to get to the device  
> pixels, that's their purpose, making them not do that is both  
> bizarre, breaks the semantic that  
> putImageData(getImageData(x,y,w,h), x, y) will leave the canvas  
> unchanged
>
> Yeah, that makes sense...
>
> and the cost of sub-/super-sampling removes the whole "speed" thing  
> that the API was originally added for.
>
> Not so sure about this. Script manipulation of pixel data probably  
> isn't going to be faster than native, probably hardware-assisted  
> resampling.
Why would the sub/super sampling be done in a script?  one of the use  
cases for get/putImageData is applying filters to an image -- in that  
case you just process each pixel, no subsampling needed.
The problem comes from things like http://jsmsxdemo.googlepages.com/jsmsx.html 
  which are not using get/putImageData for image manipulation, but  
rather for just blitting to the screen.

In terms of performance, a simple testcase a wrote a while ago ( http://nerget.com/jstests/mandelbrot.html 
  ) shows that putImageData is around 200x faster than the alternative  
of lots and lots of 1x1rect fills (at least in ffx), in real world  
terms that means you can easily get to the point that just filling the  
canvas takes longer than generating the data for the fill.

> Yeah, unfortunately we all know the web authors tend to favour the  
> "it works now, so must be correct" philosophy -- it's looking more  
> and more like i will be forced to convert the canvas from hidpi to  
> 1:1 the moment any of the imagedata/toDataURL routines are used.   
> *sigh*
>
> That would break your sensible invariant that  
> putImageData(getImageData(x,y
> ,w,h), x, y) leaves the canvas unchanged.
But only the first time ther imagedata methods were touched, from that  
point on the canvas would be permanently locked at the 1:1 ratio, so  
it wouldn't result in a continual flip-flop between high and low  
resolution that would occur if you just sub/super-sampled on access.

> It would really suck to lock canvas into a 1:1 device-to-CSS pixel  
> ratio forever. Seems to me putImageData/getImageData isn't worth  
> that risk. Maybe we should introduce it later when developers are  
> more likely to encounter the DPI issues for themselves.
I'm not sure what you mean here?

> 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]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20080210/a1b9582a/attachment-0001.htm>