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

 
 

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

Submitted by:  Zou Lunkai <zoulunkai>
Submitted on:  Thu 10 May 2007 10:29:18 AM UTC  
 
Category: ActionScriptSeverity: 4 - Important
Release: NoneStatus: Fixed
Privacy: PublicAssigned to: Sandro Santilli <strk>
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)

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>
Project 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>
Project MemberIn charge of this item.
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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project 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>
Project MemberIn charge of this item.
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>
Project 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>
Project 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 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 rsavoye (Posted a comment)
  • -unavailable- added by strk (Posted a comment)
  • -unavailable- added by udog (Posted a comment)
  • -unavailable- added by zoulunkai (Submitted the item)
  •  

    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
    Fri 18 May 2007 06:58:47 AM UTCstrkStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Fri 11 May 2007 06:03:19 PM UTCstrkStatusConfirmed=>Ready For Test
      Assigned toNone=>strk
      Summarygoto_frame bugs=>gotoFrame(_currentframe-X) destroies more instances then needed
    Thu 10 May 2007 10:57:14 AM UTCstrkCarbon-Copy-=>Added udog

    Back to the top


    Powered by Savane 3.1-cleanup1