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 maxcarl...@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
