Tue 09 Oct 2007 08:02:31 AM UTC, comment #19:
Ok, thanks for the info.
In another testcase (or was it the same? can't remember).
I noticed that NDEBUG define would change CPU usage from 100% to 40%-60%. Maybe this is another case.
Probably worth another wiki page linking from http://wiki.gnashdev.org/wiki/index.php/Profiling
|
Tue 09 Oct 2007 07:48:26 AM UTC, comment #18:
Dunno how to disable rendering completely.
Disabling draw_shape eliminates 99% of the rendering process. I only see the gray background and one outline. But no change in CPU usage.
Anyway, disabling "Gui::display()" still keeps CPU usage high.
Add this to the very beginning of Gui::display():
static int counter=0;
counter++;
if (counter>50) {
printf("NOT rendering...\n");
return true;
}
It will render enough to see the start screen. Once you click on the level the screen will not change (because it already stopped rendering) but CPU goes high (from <2% to 40% on my machine).
So I think this proves that:
- it's not rendering
- it's not InvalidatedRanges (at least not the part that computes the invalidated regions)
- it's not one of the display() methods
Looks like a pure ActionScript issue...
|
Mon 08 Oct 2007 05:35:10 PM UTC, comment #17:
mmm.. can you disable rendering completely somehow ?
minimizing the window maybe ?
|
Mon 08 Oct 2007 05:03:01 PM UTC, comment #16:
Are you sure it's a render-handler problem? When turning draw_shape() into a no-op the CPU usage remains equally high. Nearly any drawing function (shapes, shape outlines, glyphs, ...) works through draw_shape().
Shrinking the window to 10% doesn't make any difference either.
I get the feeling it's not a rendering thing..
|
Mon 08 Oct 2007 09:56:36 AM UTC, comment #15:
Already attached: file #14067
|
Mon 08 Oct 2007 09:52:52 AM UTC, comment #14:
Ok, I'll have a look at it. How to compile the AS source? Or maybe please just attach the final SWF file...
|
Mon 08 Oct 2007 08:45:35 AM UTC, comment #13:
The ActionLimit seems also fixed now. CPU usage is high (not 100& though). Rendering seems broken, but gnash is responsive and you can also see score changing (the left-vertical number).
UdoG: any entusiasm in trying to figure out the rendering part ?
NOTE: I didn't test with other renderers, but no other renderer I know of supports the drawing API anyway
|
Wed 03 Oct 2007 11:25:58 AM UTC, comment #12:
I fixed a couple of ActionShiftRight problems.
This seems to fix the high memory.
Instead we now get an abort on uncought exception:
terminate called after throwing an instance of 'gnash::ActionLimitException'
what(): Loop iterations count exceeded limit of 65536. Last branch was from pc 569 to 503.
Aborted (core dumped)
|
Wed 03 Oct 2007 08:41:21 AM UTC, comment #11:
Found the culprit (or one of them):
32800 >> 5 (ActionShiftRight)
should give 1025, while in gnash it gives -1023.
|
Wed 03 Oct 2007 08:00:09 AM UTC, comment #10:
The original movie is attached.
The problem of not properly running the original movie is
in ActionScript, not AGG per-se.
Anyway, sucking up all memory could be considered a problem on itself, given a malformed or even intentionally killer movie.
AGG is responsible for memory consumption. Run the result of compiling the attached source (killerdrawing.as) with gnash and another player to compare.
(file #14067)
|
Wed 03 Oct 2007 07:51:42 AM UTC, comment #9:
Any change to get the source / decompile the original SWF to see how it works?
Note there are lots of beginFill() but no matching endFill(). AFAIK this is legal, but does Gnash deal correctly with this?
So, AGG is not the problem?
|
Wed 03 Oct 2007 07:37:13 AM UTC, comment #8:
Added debugging support for drawing api, and the resulting drawable is really huge. The script is aborted due to action limit hit so is not complete, but the calls that went trough are enough to reproduce the problem.
Note that all drawing is outside the visible area, adding an ._y shift manually brings them inside. In the original SWF it is likely that the matrix is set before as the _y shift give us a reproduction of the actual problem.
Note also that the proprietary player is also killed by the resulting swf. The problem is of course in ActionScript, as we should likely NOT get those values, and we should get out of a loop earlier which we fail to do. Anyway it is interesting to find a way to deal with such killing scripts.
Attached is the .as file, you can compile using 'makeswf'.
|
Tue 02 Oct 2007 05:36:39 PM UTC, comment #7:
The movie is stuck trying to display this drawable:
DEBUG: Drawing the drawable of sprite _level0.pit_mc (131069 paths, 262135 edges)
agg triggers eat of all memory.
|
Tue 02 Oct 2007 04:20:32 PM UTC, comment #6:
It seems to me that CPU is busy in the rendering phase.
Action execution is aborted due to max branch-back limit.
|
Wed 26 Sep 2007 09:58:12 AM UTC, comment #5:
Confirmed, memory jumps really high.
|
Wed 26 Sep 2007 07:49:34 AM UTC, comment #4:
it hangs the whole system here, not only gnash, because it uses up all system memory quickly.
some kind of memory leak here.
|
Fri 14 Sep 2007 06:06:36 PM UTC, comment #3:
It seems it's a problem of script limits.
We're probably failing to exit from a loop (meeting loop exit condition).
Anyway, in these cases we should not hung up forever.
About hitting "script limits", should this condition abort execution of the whole set of queued actions or just a subset of them ? I mean, the whole ActionQueue or only a single element ?
|
Fri 14 Sep 2007 03:53:41 PM UTC, comment #2:
The movie runs at 24FPS and I suspect it makes aggressive use of the drawing api. I'm currently doing some optimizations and cleanups of bounds computation.
|
Fri 14 Sep 2007 06:13:10 AM UTC, comment #1:
Just a note, this is nothing new, it's a long standing bug (I guess since we implemented the drawing api)
|
Fri 14 Sep 2007 06:11:23 AM UTC, original submission:
Test case is file #12885
Once you select the level you want to play, CPU goes 100% and gnash becomes unresponsive. Gdb says it's doing hard work with drawing api.
|