[whatwg] <canvas> and ImageData

[Ian Hickson]

On Mon, 21 Jan 2008, Philip Taylor wrote:
>
> "The ImageData object's width is greater than zero." (and subsequent
> lines) is wrong, since it's talking about an object that's explicitly
> not an ImageData.

That entire section is now gone.


> What happens with NaN in imagedata.data? (NaN is a Number, so it's 
> allowed in the data array. It's not below 0, or above 255, and it can't 
> be rounded to the nearest integer.)

Changed the text so that "not a number" is now explicitly "NaN", since 
apparently NaN, despite standing for Not A Number, is a number...


On Mon, 21 Jan 2008, Oliver Hunt wrote:
>
> I was just doing some putImageData tests last night, and found that 
> firefox does not allow putImageData to specify a target that extends 
> beyond the bounds of the canvas.  Given that getImageData can request 
> bounds that extend beyond the canvas region (3.14.11.1.10) I would 
> expect to be able to use putImageData in a similar manner, eg. 
> canvas.putImageData(canvas.getImageData(-50,-50,200,200), -50, -50) 
> should succeed.

Fixed.


On Wed, 23 Jan 2008, Oliver Hunt wrote:
>
> I noticed that the behaviour is undefined if putImagedata is provided an 
> ImageData object on which the width, height, or data member is a getter 
> that throws an exception.

Can't happen any more.


> Ooh, and a request for a feature.  It would be great if putImageData 
> could take a source region, in addition to the destination.  One of the 
> primary reasons for using get/putImageData is to allow JS to rapidly 
> blit data to the screen, however without an ability to blit only a 
> subregion of the image data the only available options are to either 
> re-blit the entire imagedata region (which can be expensive due to the 
> need for [un]premultiplying in some (all?) implementations), or create 
> and populate a new ImageData object which still requires more work than 
> would ideally be necessary.

Added, using the signature suggested below.


On Fri, 25 Jan 2008, Oliver Hunt wrote:
>
> void putImageData(in ImageData imagedata, in float dx, in float dy);
> void putImageData(in ImageData imagedata, in float dx, in float dy, in float
> dirtyX, in float dirtyY, in float dirtyWidth, in float dirtyHeight);
> 
> Where the dirtyX and dirtyY are relative to the ImageData's origin.
> 
> The repaint region would be (dx+dirtyX, dy+dirtyY), dirtyWidth*dirtyHeight in
> the canvas domain

Not sure which domain that is supposed to be. Do you mean the canvas 
author-specified coordinate space, or the canvas device coordinate space?

Right now the spec assumes that the dirty* arguments are in the device 
coordinate space.


On Fri, 25 Jan 2008, Adam Roben wrote:
> 
> I think it would be less confusing for the repaint region to always have 
> its origin at (dx, dy). This would be more similar to Windows' BitBlt 
> API. Something like:
> 
> void putImageData(in ImageData imageData, in float destX, in float 
> destY, in float srcX, in float srcY, in float width, in float height)
> 
> destX and destY are in canvas coordinates
> srcX and srcY are in ImageData coordinates
> 
> The data from the ImageData in the rectangle specified by (srcX, srcY, 
> width, height) is then painted into the canvas in the rectangle (destX, 
> destY, width, height).

That's basically what I've done, if I'm understanding correctly.


On Fri, 25 Jan 2008, Oliver Hunt wrote:
>
> The problem in that case is that it would not be backwards compatible -- 
> eg. puImageData(data, destx, desty, srcx, srcy, width, height)

With the arguments in the order you suggested, I think it is.


On Sat, 26 Jan 2008, Anne van Kesteren wrote:
> 
> Note that we already have a difference between canvas pixels and CSS 
> pixels. One could easily do this for high definition displays:
> 
>   <canvas height=1000 width=1000 style=height:100px;width:100px>
> 
> (Might be a bit much.)

The height and width attributes don't give the dimensions of the backing 
store, only of the coordinate space. That might have no bearing whatsoever 
on the backing store.


On Fri, 25 Jan 2008, Oliver Hunt wrote:
>
> Another thing that we need is some way to determine what the device 
> pixel->css pixel ratio is.  Currently there's isn't even a real way to 
> tell that it's 1:1 -- you would have do do a fillRect(width-1, height-1, 
> 1, 1),; then getImageData(width-1, height-1, 1, 1) and see if they 
> match.  Conceivably you could do this multiple times to estimate the 
> ratio, but it would be non-trivial.

Why would you need that data?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'