[whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio

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<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.
> 
> 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

Received on Wednesday, 21 March 2012 20:58:55 UTC