Recent Posts
Skia, RTTI, and C++ exceptionsNew source code license
Forward Compatibility
Color with alpha
June Progress
(All Posts...)
Source Code
Issues
Data Recovery Jun 14, 2015
From v1.1-beta3, Aseprite includes a data recovery feature. It was originally planned for v1.3, but as several new internal refactors were made for v1.1 (increasing the probability of crashes), it was rescheduled for v1.1 milestone.
When the program crashes and you execute it again, it tries to restore sprites that were being edited before that crash. Then it shows you this huge horrible button at the top to start the recovery process:
But, how does this exactly work?
All objects in the doc layer has a specific ID and version properties. Every single time we modify a sprite this version is incremented. (E.g. when we draw something, move a layer, change a layer name, etc.)
So when the program starts, it launches a background thread to save your modifications every 2 minutes. This period is configured in Edit > Preferences:
To save the modifications, this thread locks the sprite with a DocumentReader lock, compares all document’s internal object versions (layers, cels, images, etc.), and if something has changed, that specific object is re-saved on disk. Here is a demonstration of one sprite and its session folder:
These little files contain the internal state of each object. When a document is closed, the folder is completely deleted, but if the program crashes, it remains and then a next instance of Aseprite can restore the sprite from the folder.
Tip: The only way to do something like this is accessing to your business layer with read and write locks each time you want to see or modify your document structure. On Aseprite, documents have read and write lock counters: only multiple read locks are allowed, and a write lock can be only obtained if there is no other reader (or we want to convert a reader to a writer lock).