I'm looking at this, but I'm concerned there is a deeper issue here.
My take: The way people are expected to create repeating events in
LZX is to have the event reschedule itself by calling addTimer. This
tickles a bug in swf9. Perhaps a GC issue? Perhaps because of
calling setTimeout from within an event that is triggered by a timeout?
Can we try to create a work-around for the swf9 issue before we change
the LZX API?
On 2009-02-17, at 12:46EST, André Bargull wrote:
This is a proposal how to fix LPP-7763 ("LzTimer hangs the system").
AFAIK, we need an API change to get around the flash player issue.
Change 20090217-bargull-Ada by barg...@dell--p4--2-53 on 2009-02-17
18:25:23
in /home/Admin/src/svn/openlaszlo/trunk
for http://svn.openlaszlo.org/openlaszlo/trunk
Summary: add repeat counter to addTimer and resetTimer
New Features: LPP-7763
Bugs Fixed:
Technical Reviewer: ptw
QA Reviewer: (pending)
Doc Reviewer: (pending)
Documentation:
Release Notes:
Details:
Add a new feature to lz.Timer#addTimer and resetTimer to accept the
number of repetitions for the timer.
This helps to avoid an issue in swf9, where the flash player needed
more and more cpu resources.
A call looks like:
lz.Timer.addTimer(delegate, 1000, 10) -> execute the given delegate
10 times in an interval of one second
Or: lz.Timer.addTimer(delegate, 1000, Infinity) -> execute the given
delegate infinite times in an interval of one second
The implementation relies on the fact that clearTimeout and
clearInterval are interchangeable in all runtimes.
Q: What should be the default value of "repeat": 0 or 1? Just asked
because in lz.animatorgroup the "repeat" attribute describes that
repeat = 1 means one execution, so that one repetition is equal to
one execution, at least in OpenLaszlo-terms ;-) Should we be
consistent to that implementation for the addTimer/resetTimer repeat-
argument?
Tests:
Files:
M WEB-INF/lps/lfc/services/LzTimer.lzs
Changeset: http://svn.openlaszlo.org/openlaszlo/patches/20090217-bargull-Ada.tar
