[whatwg] putImageData() and getImageData()

[Philip Taylor]

On 12/05/07, Anne van Kesteren <annevk at opera.com> wrote:
> The best way forward would probably be to get rid of "<canvas> device
> pixels" and just make such a pixel map a <canvas> pixel. This means that
> getImageData() and putImageData() work similarly to toDataURL() and
> drawImage(). If people really want high resolution <canvas> they could
> just make it high resolution and scale it down for display using CSS.
> Incidentally such an approach might get us rid of all the floats currently
> in the API...

With those pixels being the same (i.e. a <canvas width=100 height=100>
will always make the browser create a 100*100*4 byte array to store
the data and to work in, regardless of what size it's finally going to
be drawn to the screen), then it would be helpful to get rid of floats
only in getImageData/putImageData.

It's still sensible and useful to e.g. draw rectangles at float
coordinates, because of antialiasing - if you do fillStyle='white';
fillRect(0, 0, 0.5, 0.5) so one pixel is 25% covered, then it will be
approximated by setting one canvas pixel ( = one <canvas> device
pixel, i.e. 4 bytes in the canvas's backing bitmap) to rgba(255, 255,
255, 0.25).

This is how existing browsers handle it, e.g.
http://canvex.lazyilluminati.com/misc/subpixel.html - they approximate
subpixel rendering by doing antialiasing into a 3x3 bitmap, and then
eventually scale the 3x3 bitmap up just before drawing to the screen.
(Opera does that final scaling by repeating each pixel, Firefox does
it more smoothly with some interpolation, but in both cases the canvas
is originally drawing onto a 3x3 pixel bitmap.)

This would disallow people from implementing antialiasing via
supersampling, e.g. storing 8x8 subpixel values per canvas pixel and
then scaling downwards when rendering, because
putPixelData(getPixelData()) would require only one colour value to
exist for each canvas pixel. But it seems nobody implements it with
supersampling now, probably because it uses far too much memory and
normal antialiasing is a good enough approximation - I currently think
the predictability and simplicity of requiring one storage pixel per
canvas pixel is worth that theoretical limitation. (And if somebody
wants higher-resolution output, they can still do <canvas width="800"
height="800" style="width:100px; height:100px">.)

-- 
Philip Taylor
excors at gmail.com