Mon 10 Dec 2007 04:19:33 PM UTC, comment #13:
Better start a new bug for the opcode guard... if we need another case
|
Mon 03 Dec 2007 09:04:49 AM UTC, comment #12:
mergeDisplayList() itself has speed a complexity of o(OldList.size()) + o(NewList.size()), since both lists are already sorted.
> but really I don't see how the new mergeDisplayList should fix
> the problem of executing all tags in all frames...
I guess the speed was improved by simplifying executing PlaceObject tags. And this file is lucky because it resulting hundreds of PlaceObject tags when jumping back.
|
Mon 03 Dec 2007 08:42:30 AM UTC, comment #11:
I confirm that with NDEBUG defined zou patches make the problem NOT noticeable. Impressing :)
|
Mon 03 Dec 2007 08:23:24 AM UTC, comment #10:
I still see the 100% cpu problem (with --enable-cassert).
Tested with --enable-cassert disabled and code before zou commit and it's actually better (I'm sure DisplayList::testInvariant has its role here).
I'll test with head and --enable-cassert removed, but really I don't see how the new mergeDisplayList should fix the problem of executing all tags in all frames...
|
Mon 03 Dec 2007 08:02:20 AM UTC, comment #9:
> Play it till Alfy and Havoc (the doc) are outside and it's your
> turn to click on the butterfly. Don't click there, just see what
> happens with a system monitor.
> The loop is: the dog jumps and moves his tail twice.
> At the end of loop, CPU goes up 100% and GUI is unresponsive for > some time, then restarts fine, and this goes in circle again.
The CPU busy problem is gone here. Remaining problem should be with opcode guard.
|
Mon 19 Nov 2007 07:53:30 AM UTC, comment #8:
Made more tests, and 4th attempt of timeline control is still bogus . We probably need a new model again. I'll work on testcases first.
|
Sun 11 Nov 2007 04:24:40 AM UTC, comment #7:
I'll handle this bug this week if no one works on it.
|
Fri 09 Nov 2007 03:03:16 PM UTC, comment #6:
I have the same same problem after clicking on the butterfly (it goes back to the beginning). It happens as soon as I move the mouse pointer after clicking on the butterfly. Until then it keeps playing as normal.
|
Fri 02 Nov 2007 09:59:29 AM UTC, comment #5:
I confirm I saw such behaviour, but not always consistently.
In SWF4 it seems the syntax was something like this:
tellTarget(x) {
....
}
Which might mean that if we don't find X we omit the whole
block. Could also be related to opcode guard, in which
case falling off the end of block [ setTarget("") ? ]
should resume execution.
|
Fri 02 Nov 2007 09:34:14 AM UTC, comment #4:
strk, another bug with this file:
after clicking the butterfly, the movie went to frame1 and stop there, which is unexpected. Can you confirm this?
I think it's related to interpreting setTarget('a_unloaded_sprites')...
|
Fri 02 Nov 2007 02:35:05 AM UTC, comment #3:
> or review the timeline control model again to see if we have
> better a solution
eg. Analysing the timeline of the target frame and avoid executing some place/remove tags with no onClipAction associated, thus avoid executing some character constructions and destructions.
|
Fri 02 Nov 2007 02:18:02 AM UTC, comment #2:
> File was too big, uploaded here:
Thanks:) this is very important to me, otherwise I'll need a long time to download it.
Confirmed, I can reproduce this problem here.
ActionScripts in this file are pretty simple, some gotoFrames and few setTargets.
I believe the high CPU problem is caused by the speed ineffective implementation of 'gotoFrame', especially backward 'gotoFrame'. In our model, at frameX, gotoFrame(X-1) would result re-executing all frame tags from frame0 to frameX. This is very expensive when X is a big number.
In this movie(alfy-havoc.swf), this first high CPU occurs at root frame1341(1-based). This frame contains one action command 'gotoAndPlay(1323'). This would cause gnash re-execute all tags from frame0 to frame132, and then frame1323 to frame1341, and then repeat the process again and again since no 'ActionStop' command there. Construction and destruction of some characters are very expensive(eg. sprites and editText), even they are (sometimes)useless in the backward gotoFrame process. Another example related this problem is bombgame.swf, when you guide the bombman walk to the left(trigger backward gotoFrames), the movie plays very slow. When to the right(trigger forward gotoFrames), the movie plays smoothly.
To help fixing this 'bug'(is it a bug?), I think we need some light character constructors(eg. lazy initialization hack), or review the timeline control model again to see if we have better a solution.
|
Thu 01 Nov 2007 05:29:28 PM UTC, comment #1:
File was too big, uploaded here:
http://foo.keybit.net/~strk/tmp/alfy-havoc.swf
|
Thu 01 Nov 2007 05:22:33 PM UTC, original submission:
The attached movie (alfy-havoc.swf) shows an interesting behaviour which seems related to a gotoFrame.
Play it till Alfy and Havoc (the doc) are outside and it's your turn to click on the butterfly. Don't click there, just see what happens with a system monitor.
The loop is: the dog jumps and moves his tail twice.
At the end of loop, CPU goes up 100% and GUI is unresponsive for some time, then restarts fine, and this goes in circle again.
The same movie has other problems (sound-related) but I'll open another bug report for them.
|