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

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?

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

Received on Wednesday, 21 March 2012 20:31:00 UTC