Re: [whatwg] High-density canvases

[Resurrecting old thread]

On Tue, Sep 10, 2013 at 12:00 PM, Ian Hickson <ian@hixie.ch> wrote:

> It would be nice to fix these all at once, and I think we can, by
> introducing a configuration option on getContext(), in the style of WebGL:
>
>    getContext('2d', { density: 'autosize' });
>
> This would trigger the following behaviour: When the context is created,
> and subsequently when the <canvas> changes size (e.g. due to being sized
> with CSS relative units and the element they're relative to changing), or
> when the display density changes size (e.g. due to page zoom), then:
>
>    - the width and height of the canvas bitmaps get updated to match the
>      new native size of the <canvas>, at native density.
>
>    - the coordinate space of the canvas (context.width/context.height)
>      gets updated to match the size of the <canvas> in CSS pixel units.
>
>    - a 'resize' event gets fired at the <canvas>.
>
> We would dump the *HD versions of the methods, and make the regular ones
> go back to returning the actual raw pixels, since that would now work fine
> and still provide HD-quality content everywhere it's available.
>
> What do people think?
>

I think I'd rather not take control of canvas resizing away from
applications, even opt-in. That leads to complexity such as extra API for
slaving other canvases. I also think we'd be better off sticking to the
invariant that the units of canvas coordinate space are single pixels in
the canvas bitmap; I think that simplifies things for implementers and
authors.

Here's an alternative proposal which I think is a bit simpler and more
flexible:
Expose two new DOM attributes on HTMLCanvasElement:
    readonly attribute long preferredWidth;
    readonly attribute long preferredHeight;
These attributes are the UA's suggested canvas size for optimizing output
quality. It's basically what Ian's proposal would have set as the automatic
size. We would also add a "preferredsizechange" event when those attributes
change.

Applications that want DPI-aware canvases would read those attributes and
use them to set the size, just once if they only want to paint once, during
each requestAnimationFrame callback for games and other animations, and in
the preferredsizechange event handler if they are willing to paint multiple
times but aren't actually animating. The application would be responsible
for scaling its output to the new canvas coordinate space size. Giving the
application control of the size change simplifies things for the browser
and gives applications maximum flexibility, e.g. resizing ancillary
resources as needed, or imposing constraints on the chosen size.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w

Received on Friday, 13 June 2014 03:43:25 UTC