On Feb 10, 2008, at 12:41 AM, Robert O'Callahan wrote:
On Jan 26, 2008 11:57 AM, Oliver Hunt <[EMAIL PROTECTED]> wrote:
Another thing that we need is some way to determine what the device
pixel->css pixel ratio is. Currently there's isn't even a real way to
tell that it's 1:1 -- you would have do do a fillRect(width-1,
height-1, 1, 1),; then getImageData(width-1, height-1, 1, 1) and see
if they match. Conceivably you could do this multiple times to
estimate the ratio, but it would be non-trivial.
I think we have to be careful exposing that ratio to Web developers.
With the current ImageData spec it seems too easy for developers to
assume a 1:1 ratio, notice that everything works in their tests, and
deploy lots of content which breaks when a browser tries to Do The
Right Thing on some other device, so we'll all just end up having to
fix the ratio at 1:1 (or at least do something equivalent for
ImageData).
(Gecko 1.9 allows the ratio to vary in general for Web content,
either due to a high-DPI display device or due to user zooming, and
things work pretty well because there is no way for Web content to
detect, or depend on, the ratio. Unfortunately <canvas> doesn't
currently change its internal buffer size to match.)
So for ImageData, how about making the image data array have, by
default, one pixel value per canvas coordinate unit? If we really
need to expose a higher-resolution underlying buffer, then add an
API to get the device-pixel per canvas-coordinate-unit ratio, and
extend createImageData and getImageData so the ImageData array
dimensions can be given as optional extra parameters. Then it would
be hard for an author to be surprised by an unexpected ImageData
array size.
My original question was due to a mis-understanding of the spec, and i
am completely happy with the way put/getImageData behave with respect
to hidpi devices as currently specified (ignoring the issue of
webdevelopers who blindly assume that just because it works now it
will always work).
That said, basically what you're saying is that canvas should not
support hidpi. At all. There is no need to request the dpi of a
canvas, but (and here's the critical bit) you can't have get/
putImageData work at a different resolution from the backing buffer.
Their sole purpose is to be a 1:1 mapping to the canvas backing store,
so saying get/putImageData should work in canvas pixels and not device
pixels seems to defy the whole reason for this API existing.
Rob
--Oliver
--
"He was pierced for our transgressions, he was crushed for our
iniquities; the punishment that brought us peace was upon him, and
by his wounds we are healed. We all, like sheep, have gone astray,
each of us has turned to his own way; and the LORD has laid on him
the iniquity of us all." [Isaiah 53:5-6]