W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2009

[whatwg] getImageData/putImageData comments

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 01 Jun 2009 00:09:45 -0700
Message-ID: <E39E0113-762C-41F6-ACB1-898399265CB0@apple.com>

On May 31, 2009, at 6:55 PM, Boris Zbarsky wrote:

>

>   3)  It's not clear to me why imagedata actually exposes device  
> pixels,
>    nor is it clear to me how this is supposed to work if the same
>    document is being rendered to multiple devices.  Is a UA allowed
>    to have a higher internal resolution for a canvas (in device  
> pixels)
>    and then sample when painting to the device?  This might well be
>    desirable if the UA expects the canvas to be scaled; it can well
>    reduce scaling artifacts in that situation.  It doesn't seem
>    reasonable, to me, to expose such super-sampling via imageData;
>    it's entirely an optimization detail.
> Worse yet, the current setup means that a script that tries
>    createImageData, fill in the pixels, and then paint it to the
>    canvas, needs to fill different numbers of pixels depending on the
>    output device.  I fully expect script authors to get this very very
>    wrong, since it's such non-intuitive behavior.  It would make more
>    sense to just have the script work entirely in CSS pixels; if it
>    wishes to create a higher-resolution image it can create a canvas
>    with bigger dimensions (and scale its actual display via setting
>    its width and height CSS properties).

In some environments, a CSS pixel may be more than one device pixel.  
In this case, getImageData followed by putImageData will lose  
resolution. In other cases, a CSS pixel may be a non-integer number of  
device pixels.

To see an example of a browser running in this environment, on Mac OS  
X launch Quartz Debug, open the User Interface Resolution window, and  
try setting the scale factor to 1.5 or 2.0. In this case in Safari,  
the CSS px unit will respect the scale factor, but the canvas backing  
store will still be in device pixels so users get the benefit of the  
higher resolution. (Currently Apple doesn't ship any systems that use  
a non-1.0 UI scale factor by default.)

The current design makes it possible to write code that will do the  
right thing in a scaled UI. It also makes it easy to do the wrong  
thing and copy only a fraction of the area intended. The alternate  
design of using CSS pixels would make it impossible to get right, but  
the failure mode would just be to lose resolution.

Regards,
Maciej
Received on Monday, 1 June 2009 00:09:45 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:12 UTC