On Mar 21, 2012, at 8:31 PM, Charles Pritchard wrote:
> 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?
We think both those changes are required to handle all cases gracefully.
>
> 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.
I'm not sure what you mean by that. As I mentioned, backingStorePixelRatio is
in general not equal to devicePixelRatio. It's true that you might be able to
infer the backing store scale by creating a canvas solely for testing, but that
is needlessly awkward.
>
>
>> 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.
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.
Regards,
Maciej
