[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-commit] gnash ChangeLog gui/gtk.cpp server/sprite_insta...
From: |
Sandro Santilli |
Subject: |
Re: [Gnash-commit] gnash ChangeLog gui/gtk.cpp server/sprite_insta... |
Date: |
Thu, 8 Mar 2007 12:34:25 +0100 |
On Thu, Mar 08, 2007 at 09:42:25AM +0100, Udo Giacomozzi wrote:
> Hello Sandro,
>
> Thursday, March 8, 2007, 1:11:13 AM, you wrote:
> SS> + // forgive me udo, I'll leave correct thing to you
> SS> + set_invalidated();
>
> Since you call execute_frame_tags() later, it should be unnecessary to
> call set_invalidated() at this time. AFAIK, execute_frame_tags()
> updates the display list if necessary and will trigger
> set_invalidated() itself.
Udo, you designed this set_invalidated() thing yourself.
I had hard times understanding it, but finally got it, and found
out that it is *important* that it is called *before* any change
happens. I added this info to the corresponding header files
(see NOTE in character::set_invalidated - character.h).
Now, we are *clearing* the DisplayList here, so set_invalidated
must be called *before* that. What am I missing ?
> SS> m_current_frame = 0;
> SS> m_update_frame = true;
>
> What's m_update_frame? I don't see it being used anywhere..
Dropped.
> SS> + // DisplayList::clear is bogus in that
> SS> + // id won't recursively call character::unload
> SS> + // unless we pass 'true' as the second argument.
> SS> + // But passing 'true' will also call the onLoad
> SS> + // method, which is wrong.
>
> Really? Clearing the displaylist calls onLoad? Or is this a typo?
It's specified in a parameter, either does or doesn't, but on
characters in the displayList, not on the sprite_instance containing it.
Anyway, I've rolled this back to NOT call onUnload. Should work fine.
> Also, is clear() *only* being called for character::unload? Because in
> this case execute_frame_tags() will certainly trigger
> set_invalidated() since the display list needs to be rebuilt.
No, clear() is called to wipe out the DisplayList, we're ::restart(ing)
from scratch (I think).
> And, could you please document all the known facts about restart() in
> the code? Should sprite_instance::restart() really restart all of it's
> children? In what situations is restart() being called? What is it
> opposed to do?
I think it should only restart itself, dropping all children, and restarting
from scratch. I touched this function to implemente MovieControl->Restart (gui).
Should be fine as a behaviour for button_instance too. You tell me.
> I saw lots of discussions about these things in IRC and elsewhere
> (didn't follow everything, though). We should write down all the
> results so far, somewhere.
IRC discussion was about actions execution order. I setup a wiki page
to help the discussion:
http://gnash.lulu.com/wiki/index.php/ActionsExecutionOrder
Ann, how to register ?
--strk;