On Thu, Jun 19, 2014 at 7:03 PM, Robert O'Callahan <rob...@ocallahan.org>

> On Fri, Jun 20, 2014 at 7:32 AM, Justin Novosad <ju...@google.com> wrote:
>> +1 from me too. But I have one concern in terms of future proofing,
>> because
>> I would like to keep the door open for auto-resizing as a possible future
>> improvement. In an eventual auto-resize proposal, we will want to make
>> the "preferredsizechange"
>> event cancelable.
> Why?

Because apps may want to use the auto resizing feature to delegate the
resize math to the browser (and possibly the re-rendering too, in the case
of a command-buffer backed implementation), but still retain some control
over when the auto-resizing kicks in.  A simple way to provide that control
is to allow the app to inhibit an auto-resize by cancelling the
preferredsizechange event.  It could be done differently, but I think
making the event cancelable would be the most natural and succinct way to
expose that control.

Examples of how this might be used:
* If the CSS size of the canvas is being animated, the app may want to only
allow the backing store to be auto-resized at the end of the animation, so
that the animation stays fluid.
* The app may want to allow auto-resize to kick-in only when the preferred
vs actual size ratio exceeds a certain threshold.


> 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

Reply via email to