bugGnash - The GNU Flash player - Bugs: bug #19847, gotoFrame(_currentframe-X)...

 
 

bug #19847: gotoFrame(_currentframe-X) destroies more instances then needed

Submitter:  Zou Lunkai <zoulunkai>
Submitted:  Thu 10 May 2007 10:29:18 AM UTC
   
 
Category:  ActionScript Severity:  4 - Important
Release:  None Status:  Fixed
Privacy:  Public Assigned to:  strk
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 22 May 2007 09:34:45 AM UTC, comment #10: 

Seems good! :)

I see some issues with invalidated bounds (too much is being invalidazed) and will have a look at this now.

Udo Giacomozzi <udog>
Group Member
Fri 11 May 2007 06:03:19 PM UTC, comment #9: 

My last commit (NEW_TIMELINE_DESIGN) seems to fix this.

Sandro Santilli <strk>
Group Member
Thu 10 May 2007 09:38:48 PM UTC, comment #8: 

This scenario from the wiki is related to the "too many characters destroyed" thing:

http://www.gnashdev.org/wiki/index.php/TimelineControl#Jumping_backward_to_the_midle_of_a_character.27s_lifetime_after_static_transformation

Gnash fails in that it doesn't keep the current object alive.

Sandro Santilli <strk>
Group Member
Thu 10 May 2007 02:07:44 PM UTC, comment #7: 

My gut feeling is this isn't a critical bug for the release, and I to prefer the mailing list to burying this kind of discussion in bugzilla.

Rob Savoye <rsavoye>
Group administrator
Thu 10 May 2007 01:58:00 PM UTC, comment #6: 

Agreed, the bug is useful in case we want to make this bug a show stopper for upcoming release, in which case we'd set it's priority to "Blocker"...

Sandro Santilli <strk>
Group Member
Thu 10 May 2007 01:47:31 PM UTC, comment #5: 


> Do we all agree on this ?


Yes, but it's still complex and I don't this is a good place for discussions...

Udo Giacomozzi <udog>
Group Member
Thu 10 May 2007 12:01:41 PM UTC, comment #4: 

I think we should use the wiki to find out what the expected behaviour is.

I asked zou to open this bug item so that it is ONLY
related to the actual BUG (discarding the performance
problem here).

The focus of this bug item is:

"When jumping back, more characters got destroied than expected"

Do we all agree on this ?

Sandro Santilli <strk>
Group Member
Thu 10 May 2007 11:38:08 AM UTC, comment #3: 

Do we really want to continue the discussion here? I prefer mailing list threads...

> /// I assume that item.getDepth() returns the depths value
> /// defined in the placeObjet* tag;


no, calling swapDepths() changes the value returned by getDepth()

> (is_script_created
> && new_depth fall into static range depths
> && new_depth != item.getDepth() )


What is new_depth and what is item.getDepth() in this case? Do you mean "all items that are still at the depth defined in placeObject*" ?

For the rest you should go through all cases described on the Wiki page.

>(2)excute frame tags from frame_1 to target_frame. Do not re-create(for
>PLACE) any character if the specified depth is already occupied(this is
>already true curently).


You should specify what exactly needs to be executed.

I think your model is good. After all it's more or less what we discuss on the Wiki page.

Udo Giacomozzi <udog>
Group Member
Thu 10 May 2007 11:13:32 AM UTC, comment #2: 

I think I don't get full understand about theTimelineInfo records things. My connection to wiki is too slow. I'd like to add my pesudo code here to show how to reconstruct the DisplayList when jumping back in my model.

DisplayItem
{
boost::intrusive_ptr<character>  item;
 
/// the depth in the display list;
/// I assume that item.getDepth() returns the depths value
/// defined in the placeObjet* tag;
int new_depth;  <------------ [1]
 
/// the frame number at which the item is created;
/// take swapDepths(depth) as creating a new item; <-----[2]
int created_at_frame;
 
/// true if the item is script-created, including created by
///   swapDepths();
/// false if the item is tag created;
bool is_script_created;
}


(1) scan the DisplayList, remove the DisplayItems satisfied one of(a) or (b);
(a) if the follow condition is true
(is_script_created
&& new_depth fall into static range depths
&& new_depth != item.getDepth() )

(b) if the follow condition is true
(!is_script_created
&& created_at_frame fall into [target_frame+1, current_frame])


(2)excute frame tags from frame_1 to target_frame. Do not re-create(for PLACE) any character if the specified depth is already occupied(this is already true curently).


Notes:
[1]need this for some insane cases, just give one for example:
PlaceObject2("mc") at -16383;
mc.swapDepth(-1);     swap to another depth
mc.swapDepth(-16383); swap back
after this, mc is immune to later MOVE tags, and won't get destroied when loop/jump back.

[2]based on the 4th point in section "What "should" happen when jumping backwards" in following link
http://www.gnashdev.org/wiki/index.php/TimelineControl

any comments or any conflicts with your tests?



Zou Lunkai <zoulunkai>
Thu 10 May 2007 11:11:21 AM UTC, comment #1: 

The effect of gotoAndXXXX is a complex thematic. We try to collect information on this Wiki page:

http://www.gnashdev.org/wiki/index.php/TimelineControl

The page needs some rework, but contains lots of useful information.

Udo Giacomozzi <udog>
Group Member
Thu 10 May 2007 10:29:18 AM UTC, original submission:  

Currently, there are bugs with gotoAndPlay, gotoAndStop and related actions. These bugs might be triggered when jumping back, as more characters got destroied than needed.

More specifically, when jumping back, all characters in static range depths within frame2(1-based) to current frame get destroied(in resetDisplayList()), and all tag-based character from frame2 to target frame get re-created(in execute_frame_tags()) later. Problem1. some of the characters may not restore its prvious status as needed; Problme2. will increase some unnecessary invalidated bounds as UdoG reported.

To fix this problem, we need to make clear which characters should be deleted and re-created first, and then talk about the implementation.

Zou Lunkai <zoulunkai>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rsavoye (Posted a comment)
  • -email is unavailable- added by strk (Posted a comment)
  • -email is unavailable- added by udog (Posted a comment)
  • -email is unavailable- added by zoulunkai (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-05-18 strk StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2007-05-11 strk StatusConfirmed Ready For Test
        Assigned toNone strk
        Summarygoto_frame bugs gotoFrame(_currentframe-X) destroies more instances then needed
    2007-05-10 strk Carbon-Copy- Added udog

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code