[whatwg] putImageData() and getImageData()

[Philip Taylor]

On 12/05/07, Philip Taylor <excors+whatwg at gmail.com> wrote:
> On 12/05/07, Anne van Kesteren <annevk at opera.com> wrote:
> > These features are nice but I don't think authors will understand that
> > imagedata.height != canvas.height (likewise for width). Authors will just
> > make something that works in their browser and then assume it will work
> > everywhere else. Which would horribly break. Even the more experienced
> > <canvas> developers playing with these features have already made these
> > mistakes.
>
> Looking for people using getImageData already, I find:
> [...]
> three of those four will break when
> somebody implements getImageData with imagedata.width != canvas.width.

It may also be worth noting that it looks (as far as I can tell) like
nearly everyone (in those examples and elsewhere) is working from the
concept that a 'pixel' in the canvas coordinate space really is an
actual pixel with a single colour value, and that fillRect(x, y, 1, 1)
will draw one pixel (assuming a sensible transformation matrix and
integer coordinates).

I believe there's the same problematic assumption when you do "img.src
= ctx.toDataURL(); ...; ctx.drawImage(img)" that pixels are pixels and
it's not going to change size, but toDataURL saves each device pixel
as an image pixel (though actually that seems unspecified) whereas
drawImage draws each image pixel as one canvas pixel.

I think it would make much more sense (and be much less error-prone)
if <canvas> acted like a dynamic bitmap <img> and the browser just
scaled up the bitmap before rendering to the screen, rather than
optionally using a higher-resolution buffer for all the intermediate
drawing. That matches the behaviour when you change the <canvas>'s
size with CSS - "... the element can be sized arbitrarily by a style
sheet. During rendering, the image is scaled to fit this layout size."

It would reduce the quality of the output to some extent, but in the
current situation it seems likely that people will write code that
simply doesn't work at all when the canvas has more device pixels than
expected. Browsers already have to do as-nice-as-possible scaling for
static bitmap images on high-res/zoomed displays, so it wouldn't be
any worse than that.

For people who really do want high quality output and know what
they're doing, there could be some way to query the current
canvas->display scaling factor (taking account of high-res displays,
zoomed pages, CSS scaling, etc) and they can manually change the
canvas's width/height to get a 1:1 match between device pixels and
canvas pixels. Then they can even update the size of the bitmap every
frame, so it continues looking good if the user has zoomed in on the
page. Or they could use SVG.

-- 
Philip Taylor
excors at gmail.com