- From: Vladimir Vukicevic <vladimir@pobox.com>
- Date: Sat, 10 May 2008 16:53:54 -0700
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