W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2008

[whatwg] Yet more image data questions

From: Oliver Hunt <oliver@apple.com>
Date: Tue, 19 Feb 2008 22:00:02 -0800
Message-ID: <70532E4B-D464-4D87-BB24-CB1F9D5CAF6A@apple.com>
Hi All,
I have a few more ImageData related questions (as you may have guessed  
from the subject)

The first is relatively simple, 3.14.11.1.10 states
"If any of the arguments to createImageData() or getImageData() are  
infinite or NaN, or if either the sw or sh arguments are zero, the  
method must instead raise an INDEX_SIZE_ERR exception."

I feel this should probably be extended to throw on negative sw and sh.

Additionally sw and sh are both floats and can therefore have a  
fractional component, so this needs to be handled.  I think we should  
specify the finite value clamps in device pixels, eg.

"If any of the arguments to createImageData() or getImageData() are  
infinite or NaN, or if either the sw or sh arguments are less than one  
when scaled to the device pixel space, the method must instead raise  
an INDEX_SIZE_ERR exception."

The other issues relate to the data member of ImageData.  Currently  
this is referred to as an int array, however the DOM does not define  
such an array, and certainly doesn't specify any kind of clamping (let  
alone clamping to a smaller range than that supported by the type).  I  
think the behaviour of this "array" needs to be defined, and givevn  
that only Opera currently implements an actual ImageData type i've  
been looking at their implementation.

Assuming we have an ImageData object with width, w and height, h then  
Opera provides a data member of "CanvasPixelArray", with the following  
behaviour:
* A readonly length property is provided return the value w*h*4
* Assignment to elements [0..w*h*4) (approximately) follows the  
behaviour defined in section 3.14.11.1.10 (assignment never throws NaN  
is stored a zero which i believe is preferable)
* Assignment to elements outside [0..w*h*4) results in no clamping and  
does not alter the length property, this includes non-numeric properties
* Iteration returns only the length property and those properties that  
have been added programmatically -- iteration does *not* include  
[0..w*h*4)

By and large I am fine with this behaviour, although i would prefer  
that it were not possible to add arbitrary properties to the data  
array -- but i can't come up with a real justification for such a  
restriction :D

--Oliver
Received on Tuesday, 19 February 2008 22:00:02 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:39 UTC