W3C home > Mailing lists > Public > whatwg@whatwg.org > June 2014

Re: [whatwg] High-density canvases

From: Stephen White <senorblanco@chromium.org>
Date: Thu, 19 Jun 2014 10:54:22 -0400
Message-ID: <CAPeKFTguQgoXg73JFC2k4y5_t7LEwn3_L1YCB3UFAOUfFwvQCA@mail.gmail.com>
To: "Robert O'Callahan" <robert@ocallahan.org>
Cc: Rik Cabanier <cabanier@gmail.com>, Dean Jackson <dino@apple.com>, Ian Hickson <ian@hixie.ch>, WHAT Working Group <whatwg@whatwg.org>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:21 UTC