It's in IE in the swf runtime. I'm working on a test case, but in the
mean time check out the patch I sent you - line 269 of LzMediaLoader.as:
if ( this.mc.lmc._totalframes ==
this.mc.lmc._framesloaded){
Debug.error('done');
// TODO: this isn't working: why?
--> //this.onloaddone.sendEvent( this );
this.removeLoadChecker();
this.returnData( this.mc );
}
The onloaddone event never fired, so removeLoadChecker() never ran.
You can see the delegate being declared and registered at class init
time (line 28):
//todo: this isn't working: why?
this.removeLoadCheckerDel =
new LzDelegate( this, "removeLoadChecker", this,
"onloaddone" );
-Max
Henry Minsky wrote:
> [moving thread to laszlo-dev]
>
> Do you have a test case for that event sending failure when created at
> init? Was it also only in IE, or in IE and Firefox both?
>
>
> On 8/31/06, * Max Carlson* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> I was seeing some bizarro behavior related to LPP-2435 where an event
> registered at class init time fails to fire later when
> eventname.sendEvent is used. If there's a problem with the event
> system, it might help explain this...
>
> -Max
>
> P T Withington wrote:
> > How do we explain the erroneous behavior in the profiler
> then? I'm open
> > to other theories.
> >
> > Jim, what is the tech list you suggested we ask on?
> >
> > On 2006-08-30, at 15:45 EDT, Henry Minsky wrote:
> >
> >> Well, the test below does not show the main loop being
> interrupted by the
> >> timer process; it shows the
> >> reverse actually, the timer process does not seem to run while the
> >> main loop
> >> is executing.
> >>
> >> I have a blinking square hooked up to setInterval at 1/30 second.
> >> (note in
> >> Firefox it blinks at 30 Hz, in IE
> >> it blinks about 3 Hz)
> >>
> >>
> >> When you click on the big square it starts a main busy waiting
> loop.
> >> While
> >> that is running, the blinking timer square
> >> appears to stop blinking. I don't know exactly when the browser
> >> decides to
> >> do a screen update , but this looks like
> >> the main loop triggered by a mouse click will run exclusively
> till done.
> >>
> >> <canvas width="1000" height="500">
> >> <view id="box" width="100" height="100" bgcolor="#cccccc"
> >> onclick="main()"/>
> >> <view id="box2" width="20" height="20" x="150"
> bgcolor="#cccccc" />
> >>
> >> <text id="console" y="120"/>
> >>
> >> <script>
> >> <![CDATA[
> >>
> >> function main () {
> >> console.setText ('starting main loop');
> >> box.setBGColor(0x0000ff); // blue, start
> >> for(var i = 0; i < 800000; i++) {
> >> if (foo.bar != 259) {
> >> box.setBGColor (0xff0000); // RED, bug found
> >> return;
> >> }
> >> }
> >> box.setBGColor(0x00ff00); // green, OK
> >> console.setText('done with main loop');
> >> }
> >>
> >> foo = {bar: 259};
> >>
> >>
> >> flag = true;
> >> function frob () {
> >> if (flag) {
> >> box2.setBGColor(0xff0000);
> >> } else {
> >> box2.setBGColor(0x00ff00);
> >> }
> >> flag = !flag;
> >> foo.bar = null;
> >> for (var k = 0; k < 100000; k++) { foo.bar = null; }
> >> foo.bar = 259;
> >> }
> >>
> >> setInterval(frob, 33)
> >>
> >>
> >> ]]>
> >> </script>
> >>
> >>
> >>
> >>
> >> </canvas>
> >>
> >>
> >>
> >> On 8/30/06, P T Withington <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
> >>>
> >>> I think that is what we are going to have to do, if this turns
> out to
> >>> be true. Henry is writing a test case, but if it is true that a
> >>> setInterval call can run asynchronously with some other (long-
> >>> running) event code (say from a mouse-click), then we basically
> need
> >>> to write an 'event kernel' that dispatches the events from the
> >>> browser serially, something like:
> >>>
> >>> when an event comes in
> >>> put it on a queue
> >>> if events are being processed already, return; else
> >>> note events are being processed
> >>> while there are events on the queue
> >>> do the next event
> >>> done
> >>> note events are not being processed
> >>>
> >>> With a suitably constructed monitor to ensure that the notes and
> >>> queue are atomically updated. Which is a little tricky since
> there
> >>> is no read-modify-write primitive in Javascript, so you have to
> play
> >>> some games with multiple reads and single writes of flags for each
> >>> possible event.
> >>>
> >>> On 2006-08-30, at 14:46 EDT, Adam Wolff wrote:
> >>>
> >>> > could we just mutex lock any interrupt calls? I don't think we
> >>> > should go
> >>> > down the path of trying to handle concurrency.
> >>> >
> >>> > A
> >>> >
> >>> >
> >>> > On Aug 29, P T Withington wrote:
> >>> >
> >>> >> Henry and I have some empirical evidence that we have a
> problem in
> >>> >> the LFC.
> >>> >> After porting the profiler to DHTML, we both noticed that we got
> >>> >> weird errors
> >>> >> when running the Profiler.dump task in the 'idle loop'. The
> best
> >>> >> explanation
> >>> >> we can come up with is that `setInterval` may invoke your
> callback
> >>> >> at any
> >>> >> time, including when the application is actively executing
> >>> >> Javascript.
> >>> >>
> >>> >> This is a big departure from the SWF idle loop, which
> >>> >> (purportedly) only runs
> >>> >> your callback when there is nothing else going on.
> >>> >>
> >>> >> There is also evidence on the web (google 'javascript mutual
> >>> >> exclusion') that
> >>> >> XMLHttpRequest callbacks occur asynchronously and may
> 'interrupt'
> >>> >> your main
> >>> >> code path.
> >>> >>
> >>> >> What's the big deal?
> >>> >>
> >>> >> Well, at least in the case of the Profiler, there is a
> shared data
> >>> >> structure
> >>> >> between the profiling annotations and the background dumper. If
> >>> >> these really
> >>> >> can operate asynchronously to each other, we need a mutual
> >>> >> exclusion mechanism
> >>> >> to control access to the data structure or it may be corrupted
> >>> >> (which is what
> >>> >> Henry and I were seeing).
> >>> >>
> >>> >> If our Loader code is similarly sharing a data structure
> between the
> >>> >> application code and asynchronous callbacks without any mutual
> >>> >> exclusion
> >>> >> mechanism, it could explain some of the vagaries we have seen in
> >>> >> data-driven
> >>> >> applications.
> >>> >>
> >>> >> The trouble with race conditions is that they are seldom
> repeatable.
> >>>
> >>>
> >>
> >>
> >> --Henry Minsky
> >> Software Architect
> >> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> >
>
>
>
>
> --
> Henry Minsky
> Software Architect
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
