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!
That event isn't used anywhere I know of - other than a few test
harnesses. It's a really subtle change that I'm sure is safe!
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
--
Regards,
Max Carlson
OpenLaszlo.org
