Tupi spins to death

[kpihlblad]

Tupi allocates at least 12 GB memory and gets killed by the oom killer when opening a 320 frame long project, with not that many components.

While creating the file, it took longer and longer to copy/paste frames or elements, and I also noticed that ungrouping elements sometimes ungrouped another object - the one that the target was copied from, and some other problems related to copy/paste and selection. I got the feeling that the internal data structure somehow mixed up elements.

But it held together and I could preview my little amateurish animation, and export it to gifs.

But opening the file again and it runs out of memory.

Attaching the project.
merge5.zip

[xtingray]

Hi!
The issue you are describing is related to Windows platforms mostly and it's very annoying: the Tupi saving process falls in some kind of recursive loop, creating hundred of random frames and repeating and mixing objects in a very crazy way. It's a nightmare to try to recover one of these files, but I am trying it with yours.
I expect to work on this bug as soon as I release the next minor version of Tupi (in few days), but if I can fix your file, I expect to contact you.

PS: Can you tell me how many frames had your project before the problem? How many objects per frame? Thanks.

[xtingray]

Finally I could recover some parts of your animation. I had to split the project in several chunks to fix it. This is the link to download the files: http://www.maefloresta.com/portal/files/merge5_recovered.zip

The truth is that your project was a very good load testing for Tupi. I mean, Tupi's architecture is not designed to support large files as yours. This is an interesting issue that makes me think about to redesign the way Tupi load/save .tup files in the middle term, but for now, try to make short animations (less than 100 frames), export them, and then merge them from any video editor.

Thank you for trying Tupi! :)

[kpihlblad]

Thanks a lot!

In this case, a lot of objects where copy-pasted around, and perhaps a possible solution to reduce the size of the internal representation would be to use references rather than creating a copy.

But even a small 30 second animation would be several hundred frames that are drawn independently with a pen and tablet, so I guess that would not help much in that case.

Anyway. Thanks again!