Max Carlson | 1 May 2009 03:19
Favicon

Re: For Review: Change 20090430-maxcarlson-I Summary: Raise framerate during app initialization

What's the best way to prove the optimization works, given the fact that 
our profiler doesn't (yet) work in swf9?

P T Withington wrote:
> Not approved yet.
> 
> I'd like to see some proof that this optimization is valid before this 
> gets checked in.
> 
> Also, it seems to me that canvas.framerate ought to _always_ reflect the 
> value that it is set to (that's our rule about attributes):
> 
>   x.setAttribute('y', z) =>
>   x.y === z
> 
> Otherwise we get bug reports.
> 
> So, _if_ this optimization does buy us something, I'd propose doing it a 
> different way:
> 
> In canvas.construct, set the runtime frame rate high (why 1000?  why not 
> 1000000?  or Infinity?), and in canvas.__LZcallInit, set the runtime 
> framerate to the actual canvas.framerate.

Sounds good.  It's forced to a maximum of 1000 to deal with Flash 
limitations.

> Finally, you need to be _really_ careful about changing the timing of an 
> event (onafterinit).  I'm sure you will find some app that depends on 
> the exixting order!
(Continue reading)

Henry Minsky | 1 May 2009 03:48

Re: For Review: Change 20090430-maxcarlson-I Summary: Raise framerate during app initialization



On Thu, Apr 30, 2009 at 9:19 PM, Max Carlson <max <at> openlaszlo.org> wrote:
What's the best way to prove the optimization works, given the fact that our profiler doesn't (yet) work in swf9?

Can we just use the result of the <inittimer> tag? I thought it measure elapsed time from application load to the canvas initDone(). 

Gmane