gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Re:Serious performance problem


From: Udo Giacomozzi
Subject: Re: [Gnash-dev] Re:Serious performance problem
Date: Wed, 25 Apr 2007 14:09:42 +0200

Hello zou,

Wednesday, April 25, 2007, 1:07:15 PM, you wrote:
>>I noticed that single-frame sprites are still "advanced" in Gnash.
>>This has the effect of a ever-looping sprite and causes
>>set_invalidated() to be called in each rendered frame.

zl> I think one reason for this is all event handlers should be triggered
zl> for single-frame sprites.


You mean event handlers like onEnterFrame, onMouseDown, ...?


>>This is because advance_sprite() does not check if frames_count>1 and
>>so calls do_actions() in any case. I tried to avoid do_actions() for
>>single-frame sprites but this completely scrambles playback.

zl> This is checked by line " if (m_current_frame != (size_t)prev_frame)"

Yes, but applies only to execute_frame_tags() which is not the problem
in this case. The call to do_actions() is still done.



>>I guess also some actions get executed again, even if they shouldn't

zl> Maybe we need a testcase to verify this.  As I see, Gnash don't do this.

Ok, this was only my assumption. Can't currently verify it.


>>I failed understanding what happens in do_actions() and I don't
>>understand why it gets called for STOPPED movies at all.
zl> Yes, it's called even for stopped movies, that's confusing.  But the
zl> action list won't be filled again for stopped movies, so even if
zl> do_actions() being called again, it will do nothing actually.

That's not true actually. I backtraced the call to set_invalidated()
using gdb and it's called implicitely by do_actions(). In between this
part of the backtrace there are calls to execute_actions() and
execute_action(), ie. they're called by do_actions().

... -> do_actions() -> execute_actions() -> execute_action() -> ... -> 
set_invalidated()

Sorry I haven't got the backtrace at hand right now. Anyway, what goes
on in do_action() is beyond my understanding unfortunately. However,
do_actions() does pretty much (continuously) even for single frame
sprites.


>>At least for me this is a big problem since it causes 99% of my movies
>>to be played really slow (continuously full screen redraws) and it
>>worked fine before.
zl> I have little knowledge about the "invalidated bounds". Is this
zl> related? I cann't tell why for this...

Invalidated bounds are the areas of the stage that need to be rendered
again. Of course, larger areas require more CPU time to render. It
would be inefficient to render the whole stage again when just a tiny
part of the stage really changed. As a side effect, invalidated bounds
can detect when there has been no visual change at all.

To achieve this all characters on the stage need to call
set_invalidated() before changing anything that could require
re-rendering of themselves.

When a static character (a bitmap for example) calls
set_invalidated(), then the bounds around the character are scheduled
to be re-rendered.

Any character causes set_invalidated() to be called when it is added
or removed from a DisplayList (it appears/disappears).

A few days ago I noticed that static characters get removed and placed
again on a display list when a sprite loops back to it's first frame.

See my comment in sprite_instance.cpp::goto_frame() :

  // TODO:
  // <UdoG> current design is sub-optimal because it causes unnecessary 
  // redraw. Consider a static graphic that stays at it's position all
  // the time. When looping betwen two frames 
  //  gotoAndPlay(_currentframe-1);
  // then resetDisplayList() will remove that character and 
  // execute_frame_tags() will insert it again. So the next 
  // set_invalidated() call (which currently *is* correct) will cause
  // redraw of the whole sprite even if it doesn't change visually
  // at all.

I think (but am unable to verify) this also happens for single frame
sprites.


Now imagine a movie that uses a bitmap image for the stage background
and just moves a little sprite over it. In this case the bitmap image
causes re-rendering of the whole stage even if just the area around
the sprite needs to be really re-rendered. This is a typical scenario
for Flash movies (it is not relevant that it is a bitmap image).

This means invalidated bounds became practically useless with recent
changes... :(


Now someone who has better understanding of action execution would
need to have a look at this.


Udo





reply via email to

[Prev in Thread] Current Thread [Next in Thread]