Ticket #151 (assigned defect)

Opened 7 years ago

Last modified 6 years ago

Undo doesn't scale for large EDLs

Reported by: uhauufo02@… Owned by: cinelerra@…
Priority: medium Milestone:
Component: User Interface Version: 1.2.2
Severity: normal Keywords:
Cc:

Description

Undoable operations like moving the in point currently push the entire xml file
to a stack. For a large file, like 5 MB, this both takes a long time to do and
quickly fills up the available memory.

Attachments

bug151-20050306.patch Download (13.1 KB) - added by uhauufo02@… 7 years ago.
Patch with implementation of recommended solution

Change History

Changed 7 years ago by uhauufo02@…

Recommended solution:
I recommend limiting the undo stack size, not just the number of entries. I
also recommend creating an "Undoable" object that is pushed on the undo stack
instead of the entire EDL state. The Undoable object can be a virtual object
with undo and redo methods and whatever data it needs to run those methods. For
example, moving the in point just requires remembering the track and the
original position. An undoable object that saves and restores the entire EDL
can be created to preserve backward compatibility and prevent overhauling every
undoable operation at once.

I'll get a patch together as soon as possible with an implementation.

Changed 7 years ago by uhauufo02@…

Patch with implementation of recommended solution

Changed 7 years ago by andraz.tori1@…

this is cool solution, but i am afraid that implementing it for edit changes
will be a pain in the ass...

please send a patch to heroine directly also, so it gets integrated in mainline too.

is this patch well enough tested that i can commit to CVS?

herman will take care of your cvs access.

Changed 7 years ago by uhauufo02@…

  • status changed from new to assigned

I know that implementing this will be painful, but it will be worth it and the
backward compatibility takes the time pressure off. I've used this patch for a
while to work on finishing the same project that prompted the bug report, with
great results. Already my editing feels a lot faster with just the changes for
these 3 edit types. I'd say it has been tested enough to commit.

I'm still not clear on the relationship between heroine and unofficial cvs.
They won't get the change without an email? Do they need an email for every cvs
commit or does someone collect them to submit at some point prior to a release?

Do I diff against 1.2.2 or against the cvs version? Do I send to the

broadcast@… or somewhere else? Thanks for any clarification you can
give.

Changed 7 years ago by andraz.tori1@…

commited. debian builds are being built at the moment.

what i doubt is if it will be worth maintainance wise. ... feel free to show the
code :)

heroines don't get the patch if you don't send it trough email to them.

CVS is developed separately and then merged with each heroines release. each
patch should be sent separately to him. we are currently diverging more than i
would like, but that's how it is.

Changed 6 years ago by andraz.tori1@…

  • priority set to Critical

hello, are you doing any further work on undo functionality?

Changed 6 years ago by andraz.tori1@…

  • priority changed from Critical to Medium
Note: See TracTickets for help on using tickets.