bugGnash - The GNU Flash player - Bugs: bug #20949, invariant testing of DisplayList...

 
 

bug #20949: invariant testing of DisplayList fails playing copter.swf (head)

Submitted by:  Sandro Santilli <strk>
Submitted on:  Sat 01 Sep 2007 10:39:58 AM UTC  
 
Category: coreSeverity: 5 - Blocker
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.

 

Mon 03 Sep 2007 06:21:13 AM UTC, comment #3:

I think the problem is in the fact that we sometime use copies of DisplayList as a convenience for internal work, like the sprite_instance::oldDisplayList.

The copy will not be kept in sync, as it is agains the original
DisplayList that depth changing functions will be called.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Mon 03 Sep 2007 02:14:36 AM UTC, comment #2:

DisplayList::testInvariants() tests two points:
(1) no duplicated depths in the list
(2) characters are sorted with depths

All depth related functions in DisplayList are protected by DisplayList::testInvariants(). As I see, any depth-changer function would finally invoke a certain function in DisplayList, and then it should be caught there. I reviewed dlist.cpp, but haven't figured out a testcase to break the 'testInvariants'.

> so I'm thinking about dropping any attempt to keep
> DisplayList elements sorted by depth and just keep them in the
> order they are added, sorting a copy when needed (::display).


If not sorted, then adding a item should be faster, but removing should be slower. No big performance change.

yes, some action execution order could be fixed. But should we do it in this way(without a global list)?

Zou Lunkai <zoulunkai>
Sat 01 Sep 2007 12:22:52 PM UTC, comment #1:

Found the problem being in the invariant itself.
We can't be sure the invariant won't be broken, as depth of characters is outside of DisplayList control.
So, if any depth-changer function can be triggered
by any other character ::advance() we'll still be prone to that "invariant" broke.

I have a local patch fixing the copter.swf but I can see it can't
be robust, so I'm thinking about dropping any attempt to keep
DisplayList elements sorted by depth and just keep them in the
order they are added, sorting a copy when needed (::display).

This might actually also fix some action-execution order related
bug.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Sat 01 Sep 2007 10:39:58 AM UTC, original submission:

This happens since my commit of removed clips refactoring,
and only if version detection works (ie: parser is not too slow).

Sandro Santilli <strk>
Project MemberIn charge of this item.

 

(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 zoulunkai (Posted a comment)
  • -unavailable- added by strk (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 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 04 Sep 2007 09:00:47 PM UTCstrkStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Tue 04 Sep 2007 08:28:17 AM UTCstrkStatusIn Progress=>Ready For Test
    Sat 01 Sep 2007 10:39:58 AM UTCstrkCarbon-Copy-=>Added zoulunkai

    Back to the top


    Powered by Savane 3.1-cleanup1