Re: [whatwg] High-density canvases

On Wed, 11 Sep 2013, Dean Jackson wrote:
> 
> 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

Why? Exposing page zoom separately from device density seems like a 
fundamental abstraction failure. What's the difference between page zoom 
and native density?


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

That's precisely why we should never make page zoom detectable. The entire 
point of zooming is that the author should _not_ make things smaller. 
Zooming should make CSS pixels bigger.

Authors should always treat CSS pixels as the core unit, so if something 
should be 10 CSS pixels wide, then that's what the author should do. If 
the user happens to have zoomed in so that those 10 pixels are 30cm 
across, then that's what the user wants -- why would the author be able to 
override that?


> Yes, that’s not necessarily great content, but it makes some sense.

What sense does it make?


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

Well the context here is canvas, right?


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

Not edge cases, they're pretty core cases. srcset="" should definitely be 
influenced by page zoom, there's no question there. Otherwise, users who 
zoom in will get low quality images, which defeats the whole point.


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

Why?



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

I'm not really understanding what you're proposing here. Can you 
elaborate? What's the problem this is trying to solve? How would this work 
in a multi-worker environment?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'