[Laszlo-dev] For Review: Change 20090430-maxcarlson-I Summary: Raise framerate during app initialization

[P T Withington]

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.

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!

On 2009-04-30, at 19:36EDT, Max Carlson wrote:

> Change 20090430-maxcarlson-I by maxcarlson at Bank on 2009-04-30  
> 15:28:22 PDT
>   in /Users/maxcarlson/openlaszlo/trunk-clean
>   for http://svn.openlaszlo.org/openlaszlo/trunk
>
> Summary: Raise framerate during app initialization
>
> Bugs Fixed: LPP-8136 - Set the framerate to 1000 during app  
> initialization
>
> Technical Reviewer: ptw
> QA Reviewer: hminsky
>
> Details: framerate setter caches any values during init, setting the  
> framerate to 1000.  init() sets the framerate back to the cached  
> value.  Move onafterinit event sending to the end of init() so it  
> can be used to turn profiling back on.
>
> Tests: Startup should be slightly faster in DHTML and SWF9, where  
> the framerate can be set dynamically
>
> Files:
> M      WEB-INF/lps/lfc/views/LaszloCanvas.lzs
>
> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20090430-maxcarlson-I.tar