bugGnash - The GNU Flash player - Bugs: bug #21495, Intermittently high CPU usage ...

 
 

bug #21495: Intermittently high CPU usage (looks like gotoFrame related)

Submitted by:  Sandro Santilli <strk>
Submitted on:  Thu 01 Nov 2007 05:22:33 PM UTC  
 
Category: coreSeverity: 3 - Normal
Release: NoneStatus: Fixed
Privacy: PublicAssigned to: Zou Lunkai <zoulunkai>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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

Sandro Santilli <strk>
Project Member
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.

Zou Lunkai <zoulunkai>In charge of this item.
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 :)

Sandro Santilli <strk>
Project Member
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...

Sandro Santilli <strk>
Project Member
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.

Zou Lunkai <zoulunkai>In charge of this item.
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.

Zou Lunkai <zoulunkai>In charge of this item.
Sun 11 Nov 2007 04:24:40 AM UTC, comment #7:

I'll handle this bug this week if no one works on it.

Zou Lunkai <zoulunkai>In charge of this item.
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.

Benjamin Wolsey <bwy>
Project Member
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.

Sandro Santilli <strk>
Project Member
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')...

Zou Lunkai <zoulunkai>In charge of this item.
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.

Zou Lunkai <zoulunkai>In charge of this item.
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.

Zou Lunkai <zoulunkai>In charge of this item.
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

Sandro Santilli <strk>
Project Member
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.

Sandro Santilli <strk>
Project Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bwy (Posted a comment)
  • -unavailable- added by zoulunkai (Posted a comment)
  • -unavailable- added by strk (Submitted the item)
  • -unavailable- added by strk
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 10 Dec 2007 04:19:33 PM UTCstrkStatusConfirmed=>Fixed
      Open/ClosedOpen=>Closed
    Sun 11 Nov 2007 04:24:40 AM UTCzoulunkaiAssigned toNone=>zoulunkai
    Fri 02 Nov 2007 02:36:18 AM UTCzoulunkaiCategoryNone=>core
      StatusNone=>Confirmed
    Thu 01 Nov 2007 05:22:33 PM UTCstrkCarbon-Copy-=>Added zoulunkai

    Back to the top


    Powered by Savane 3.1-cleanup1