This patch implements dumping images from cache to HDD.
The main goal of this system is to provide a means to achieve consistent playback speed mainly for strips that are not possible to preview in real time. Function is similar to a proxy system. The main difference is, that lossless compression method is used.
In fact current non-movie proxy system could be replaced by disk cache.
Another use-case may be a storage for strip thumbnails.
(lazy copy of design notes)
For each cached non-temp image image data and supplementary info
are written on HDD. Multiple(DCACHE_IMAGES_PER_FILE) images share the same file.
Each of these files contains header DiskCacheHeader followed by image data.
Zlib compression with user definable level is used to compress image data(per image)
Images are written in oreder in which they are rendered.
Each image must have it's unique place(filename + header entry).
Overwriting of individual entry is not possible.
All images are stored in directory of blend file, or in user-defined path.
Path is human-readable to allow manual manipulation by "advanced users" (copy/delete data)
Stored images can be deleted by invalidation of cache entry.
To make this possible, we need to store information about all contexts used to render (resolution view type etc)
This is done by storing this data in cache struct and on HDD in file used_views.
When cache entry is written, data of last used context is compared to current one.
If there is any difference, we look to file on HDD and append it by current context if needed.
This could slow down performance of invalidation if a lot of contexts were used in the past.
(end of design notes)
My biggest concerns:
- I am not sure if function BLI_path_sanitize_filename is appropriate. I guess, we should support unicode in paths, and I don't know nothing about unicode, other than, I can mess up big time, if I don't know what I am doing.
- I don't have much experience with file IO, so there may be hidden bugs or room for improvement.
- use of G.main in seq_disk_cache_invalidate can be eliminated if I can store main in cache (which we do store in keys to calculate hash)
- I did not try to protect strings for building path against overflow, but seems that BLI_path functions are safe. User can choose some deep path, when things will fail silently though. Should I rather allocate memory for strings as needed?
- The way image data is saved may lead to loss of some information that cache would preserve - metadata for example. only colorspace info is stored, because it is necessary to restore float buffers properly. Ideally we would serialize whole ImBuf struct, but I didn't want to overcomplicate things now.