Re: [whatwg] High-density canvases

On Thu, Jun 19, 2014 at 7:54 AM, Stephen White <senorblanco@chromium.org> wrote:
> 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

"widthInDevicePixels" and "exactPixelWidth" both sound clear.
"renderedPixelWidth" per
https://bugzilla.mozilla.org/show_bug.cgi?id=1024493 also sounds like
a good option. It would be great to spec these and their associated
change event. I'd be interested in adding support to Chrome.

It is a little unfortunate that a canvas-specific solution is needed.
Is it known whether document.getBoxQuads solves this problem in
Firefox?

-Ken


> 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 18:07:13 UTC