[webkit-dev] Canvas backing resolution
chuck at jumis.com
Wed Apr 6 13:01:21 PDT 2011
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
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
I see adding a pixel ratio property to window.screen as the cleanest
CSS checks work, they're not slow, but they're extra work on the author,
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.
Netscape exposes the value to trusted scripts as screenPixelsPerCSSPixel
through their Utils Components interface.
More information about the webkit-dev