- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 21 Mar 2012 20:21:30 -0700
On Mar 20, 2012, at 3:22 PM, Charles Pritchard wrote: > On Mar 20, 2012, at 3:05 PM, Edward O'Connor <eoconnor at 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. 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. Regards, Maciej
Received on Wednesday, 21 March 2012 20:21:30 UTC