On Thu, Jun 19, 2014 at 7:03 PM, Robert O'Callahan <rob...@ocallahan.org>
wrote:
> 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.
-Justin
> 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
>
