On 3/21/2012 8:21 PM, Maciej Stachowiak wrote:
On Mar 20, 2012, at 3:22 PM, Charles Pritchard wrote:
On Mar 20, 2012, at 3:05 PM, Edward O'Connor<eocon...@apple.com> wrote:
Charles Pritchard wrote:
But now run through this logic when the<canvas> is making a high res
backing store automatically: by doing the clever thing, you're now
quadrupling the size of the canvas, and you're paying an exorbitant
storage cost for doing so.
Which (a): never happens
Sorry, what never happens?
The backing store itself is never set by 2x in the implementation. Not in any
public implementations I've seen. It's always 1:1 with height and width units.
We're considering the possibility of scaling the backing store in future
releases (which we can't really discuss in detail). We have experimented with
it in WebKit, and we believe it's not viable to ship a production browser with
backing store scaling without the sorts of API changes that Ted proposed
because of how much content breaks.
The change being the addition of a "backingStorePixelRatio" or the
change being the addition of a second set of "HD" items?
I get what you're saying about HD; if the user requests a non-HD, it'd
return a typical 1:1 backing store, which most sites expect.
Still, it seems a bit weird.
Why not use the method that already exists of managing the CSS and
devicePixelRatio? If an author is using new methods,
they're certainly able to use the old ones.
An automatically scaled backing store is better for authors, because for the
case where they are not doing any direct pixel manipulation, they get higher
quality visual results with no code changes on devices that scale CSS pixels.
But to offer it, we need to take care of the compatibility issues, and also
provide a path for authors who have gone the extra mile to hand-scale 1x
backing stores on 2x devices. In other words, all the following cases need to
work:
devicePixelRatio is 1; backingStorePixelRatio is 1.
devicePixelRatio is 2; backingStorePixelRatio is 1.
devicePixelRatio is 2; backingStorePixelRatio is 2.
Maybe even other possibilities. In other words, we don't want to force either
the assumption that backingStorePixelRatio is always 1, or that it is always is
equal to devicePixelRatio. We believe that in time, neither is a safe
assumption.
Well if they --need-- to work, better to add the value sooner than later.
My concern is that you've also got window.screen.logicalXPixelRatio on
the desktop.
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.
-Charles
