[webkit-dev] Canvas backing resolution

[Charles Pritchard]

On 4/6/2011 12:32 PM, David Hyatt wrote:
> He wants a way to detect Desktop zoom (which is done two different ways in WebKit).  It's difficult to figure out how to expose these, since Desktop zoom is ultimately just the CSS zoom property, which can be applied to any element (so folding it into a global makes little sense).  The other kind of Desktop zoom that involves a fixed scale factor applies a transform.  Again, transforms can be applied to descendant elements as well, so relying solely on what happened to be specified at the document level makes little sense.
The descendant elements are under the control of the author.

That is, if I decide to use  body.style.webkitTransform, in my scripting 
environment, I'm going to know that,
because I initiated the request, and I'll add that to my calculations.

Worst case, I can always walk the DOM, grab the transform style, and use 
CSSMatrix to calculate values.

With desktop zoom, the user initiates through the UA, which sends a 
resize event through to window,
but the scale is not directly exposed to the scripting environment in 
WebKit.

I am simply looking for the scale factor; this is an accessibility 
issue, for users who are using the UA zoom.

> I'm not really sure how to easily solve this problem.  I suppose we could just mix in document-level zoom and transform state into devicePixelRatio, but that feels inelegant to me given that individual child elements can change the zoom and transform.  It wouldn't necessarily be accurate.  I also don't like the idea of having to re-resolve style just because the zoom level changed.  That would just slow things down.
Current use of window.devicePixelRatio is static, we might as well keep 
it that way.
On mobile devices, authors disable UA scaling and handle the entire 
process themselves.

I see adding a pixel ratio property to window.screen as the cleanest 
solution.

CSS checks work, they're not slow, but they're extra work on the author, 
and in-elegant,
as media matches return booleans, not float values. They're inefficient, 
but not slow in any practical sense.

I'm really open to any kind of help I can give here.

I've full experience implementing the stack, from multi-level descendant 
transforms starting at document.body,
to the hacks necessary to get window.screen.pixelRatio, and still 
support an additional magnification AT,
such as ZoomText or the OS magnifier. I also have experience with 
transform3d/webgl, but that's a different issue.

I've spoken to reps from both Google (re: TV) and Microsoft about having 
distinct X and Y ratios, as MS currently does in screen.
Robert O suggested that tracking horizontal and vertical scaling 
separately was unnecessary (non square pixels)
on modern displays. Both reps agreed. It doesn't harm anything, to have 
both X and Y scale values, but it does not seem to be necessary.
http://msdn.microsoft.com/en-us/library/ms535868(v=vs.85).aspx

Netscape exposes the value to trusted scripts as screenPixelsPerCSSPixel
through their Utils Components interface.
https://developer.mozilla.org/en/NsIDOMWindowUtils


-Charles