Re: [whatwg] High-density canvases

On Thu, Jun 12, 2014 at 11:42 PM, Robert O'Callahan <robert@ocallahan.org>
wrote:

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

I agree.


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

I like this new proposal. It works for both the canvas and WebGL use cases,
and it puts the app in control of behaviour in a way that makes sense for
immediate-mode APIs.

I assume that the size change event would fire:

   - on browser page zoom
   - on pinch-zoom
   - when a CSS animation (e.g., scale) changes the canvas size in CSS
   pixels

For browsers that implement the latter two off the main thread, perhaps
they should only fire at end-of-gesture or end-of-animation, to avoid the
rendered size being out-of-sync with scaled size by the time the canvas
gets composited.

I agree with Mark that the names need work. How about something that
incorporates "device pixel" in some way, to reflect that this is roughly
dpr * css scale * size?

devicePixelWidth
widthInDevicePixels
pixelExactWidth
exactPixelWidth
pixelWidth
pixelRatioExactWidth
unscaledWidth
unscaledPixelWidth
nativeWidth
nativePixelWidth

Stephen


>
> 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 Thursday, 19 June 2014 14:54:47 UTC