- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 21 Mar 2012 21:10:03 -0700
On Mar 21, 2012, at 8:58 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> You'll really have three items now to add up.
>>
>> devicePixelRatio * backingStorePixelRatio * logicalPixelRatio.
>>
>> Is that middle item really necessary?
>> I wasn't able to get anyone to budge on changing window.devicePixelRatio on the desktop. It's fixed at 1.
>
> I was unable to decipher what IE's logical{X,Y}DPI does and how it differs from device{X,Y}DPI and for that matter system{X,Y}DPI. But I don't believe any of those things relate to the canvas backing store, however, so I don't see how they eliminate the need for backingStoreRatio.
When you zoom out or in on a page, the ratio changes. So if I check that value after a resize event I know to change the units on my canvas elements if I want them to not be blurry (when zoomed in) or if I want to not do excess work (when zoomed out).
What is the benefit of drawing to an over sized ("bush res") backing store? Seems like on a device where zoom is very common (yes, you, iphone), it could make for a little nicer experience. On desktop though, we just repaint on resize and zoom transitions are scaled through the gpu anyway.
Seems like a lot of extra work for the phone though. And we can do it as authors by just using CSS width = .5* width;
I agree with your assessment, both features are necessary to bring it in.
I'd still like someone o'er in WebKit to pick up the issue that's existed since the introduction of Canvas in WebKit: exposing the current pixel ratio so we can redraw our Canvas at the appropriate ratio when browser zoom (zoom in or out) is in use.
Currently I do outerWidth/innerWidth to estimate.
-Charles
Received on Wednesday, 21 March 2012 21:10:03 UTC