[whatwg] createImageData

On May 9, 2008, at 5:53 PM, Ian Hickson wrote:
> On Fri, 9 May 2008, Vladimir Vukicevic wrote:
>> I don't think the restriction that "putImageData" must only work with
>> objects returned by create/get is a good one
>
> This restriction was made because it allows for dramatic (many  
> orders of
> magnitude) optimisations. With createImageData(), the use cases for  
> custom
> imageData objects should be catered for -- what are the cases where  
> you
> would need another solution? (Note that hand-rolling imageData  
> objects is
> dangerous since you don't know what resolution the backing store is  
> using,
> necessarily, which is something else that createImageData() solves.)

Well, I don't agree that it's "dangerous"; canvas resolution  
independence has always been hard to pin down, and I still maintain  
that it shouldn't be treated any differently than an image is  
treated.  Canvas isn't supposed to replace SVG.  However, regardless  
of that, I don't think there's a reason to disallow custom-created  
data objects, perhaps with a caveat that there may be issues.. get/ 
putImageData in Firefox 2, so adding that restriction may  
unnecessarily break existing code that uses putImageData with a hand- 
constructed ImageData object.  I would amend the spec to state that if  
an object is passed to putImageData with the necessary properties, but  
without having been created by create/getImageData beforehand, that  
its dimensions are aways in device pixels.

One problem with the desired goal of resolution independence is that  
it only really makes sense if the target resolution is an integer  
multiple of a CSS pixel.  For example, with a 144dpi output device,  
that's exactly 1.5 times CSS resolution.  If I call createImageData  
with dimensions 10,10, I would get an ImageData object with width 15  
and height 15.  What do I get if I call it with 11,11 though?  That's  
16.5 device pixels, and you're going to lose data either way you go,  
because at putImageData time you're going to get seams no matter what  
direction you round.  This can maybe be solved with language in the  
spec that specifies that a canvas should use a different ratio of CSS  
pixels to device pixels only if one is an integer multiple of the  
other, but that seems like an odd limitation (and it still requires  
the implementation to decide what to do if a clean ratio isn't  
possible).

Another approach would be to not try to solve this in canvas at all,  
and instead specify that by default, all canvas elements are 96dpi,  
and provide authors a way to explicitly override this -- then using a  
combination of CSS Media Queries and other CSS, the exact dpi desired  
could be specified.  (You can sort of do this today, given that the  
canvas width/height attributes are in CSS pixels, and that if CSS  
dimensions are present a canvas is scaled like an image... so canvas  
{ width: 100px; height: 100px; } ... <canvas width="200" height="200"/ 
 > would give a 192dpi canvas today, no?)

>> but it would be good to have some way to mark sections of the spec as
>> stable/unstable --
>
> I've gone through and added annotations for each of the canvas  
> sections to
> distinguish the stable parts from the unstable parts. Does that work?

>> otherwise someone's liable to take a snapshot and implement it, and  
>> then
>> have it change under them if a portion is still in flux.
>
> In general, the spec is unlikely to change significantly _before_ the
> first implemenation. We get more feedback from the first  
> implementation of
> anything than from people just looking at the spec. I agree that the  
> first
> implementation should know what it's getting itself into, though. :-)

Well, it depends what you mean by "spec" -- I think that what gets put  
down as the initial spec is likely to change significantly from when  
the feature is first proposed to where it's added to the spec; I agree  
that there would be more feedback after a first implementation, but I  
don't think that means that the first proposal->spec discussion/ 
feedback period should be skipped.

The annotations do help make it clear what's in what state though,  
thanks!

     - Vlad

Received on Saturday, 10 May 2008 16:53:54 UTC