[Laszlo-dev] For Review: Change 20090430-maxcarlson-I Summary: Raise framerate during app initialization
P T Withington
ptw at laszlosystems.com
Thu Apr 30 17:01:52 PDT 2009
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
> 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
> M WEB-INF/lps/lfc/views/LaszloCanvas.lzs
> Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20090430-maxcarlson-I.tar
More information about the Laszlo-dev