[whatwg] High-density canvases

[Dean Jackson]

On 11 Sep 2013, at 6:13 am, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 11 Sep 2013, Dean Jackson wrote:
>> On 11 Sep 2013, at 5:32 am, Ian Hickson <ian at hixie.ch> wrote:
>>> On Wed, 11 Sep 2013, Dean Jackson wrote:
>>>> On 11 Sep 2013, at 12:14 am, Stephen White <senorblanco at chromium.org> 
>>>> wrote:
>>>>> 
>>>>> now that some browsers are including browser zoom (page zoom) in 
>>>>> window.devicePixelRatio
>>>> 
>>>> Ouch. Who is doing this and why?
>>> 
>>> Why ouch?
>> 
>> Because we’ve always operated under the assumption that devicePixelRatio 
>> is the mapping from CSS px to device pixels at 1:1 scale/zoom, and that 
>> it is constant for a particular display. The only change content would 
>> see is if the window is dragged to/from a high resolution screen.
>> 
>> There are other ways to query the page zoom.
> 
> That seems broken... why would you want to hide the page zoom?

We don’t want to hide page zoom.

I think there are two separate things a developer might want:

- the number of actual pixels that correspond to 1 CSS px without zoom
- the page zoom

If you merge the two, then an unsuspecting developer might think that the user has zoomed in by 2x on an iPhone, and decide to make things smaller. Yes, that’s not necessarily great content, but it makes some sense. For most page content you don’t really care about the device:pixel ratio - text looks fine! For images, you should use the mechanisms we’ve developed (srcset and image-set).

Now, I completely agree that there are going to be cases where you might want the image selected for srcset and image-set to respond to zoom. After all, there is no point loading a huge image if it is going to be 1x1 cm^2. But I think that’s separate from changing devicePixelRatio.

>> I fear this will break existing content. I don’t think we’d ever want to 
>> change the behaviour.
> 
> I guess we'll just have to treat devicePixelRatio as legacy and introduce 
> a new value that's the real device:pixel ratio, then.

Indeed. I’m not opposed to exposing this. I am reluctant to change something that has behaved a particular way for a number of years.

Meanwhile, back to canvas, why don’t we change canvas to be purely callback based, and pass in all the info a developer needs to decide what the best output should be? Put something like requestAnimationFrame into the canvas spec (although that is a bad name - it only sometimes is related to animation). That way you could even imagine a future where a single canvas could have multiple render targets (when printing you get an even higher resolution).

Dean