feature request: on-demand file mapping

[axeldavy]

Hi,

Currently the viewer seems to load some files in advance, but not too many. Memory usage increases when we see more images. Two problems I see with this approach: . When you go through the different files when stored on hard drive, it is not smooth at all (sometimes fast, then suddently slow, fast again, slow, etc). . Memory usage increases a lot when you look at a lot of things.

Fortunately there is a nice solution. But it may need some work to adapt iio for that. The solution is to map the files on demand.

Here is an example in C: data = mmap(NULL, fsize, PROT_READ | PROT_WRITE, MAP_PRIVATE, fileno(f), 0);

What happens is that when accessing data, if not in ram, it is loaded from disk. It doesn't appear in app memory allocation, as the ram content is managed by the OS. When ram is needed by other apps or yourself because you look at new images, old data is removed from ram automatically (and fetched back from disk if needed).

You can write to the buffer data, but in this case data won't be removed from ram memory (because it cannot fetch back the changes from disk. With the proposed flags, data changes don't affect the original file).

Thus at the start of the viewer, you'd load all the file headers, and read the file contents with mmap. Then when looking at the different files, it loads automatically what it needs.

[kidanger]

First of all, if the caching mechanism is too annoying for you at the moment, disable it by setting the environment variable CACHE=0.

Correct me if I'm wrong, but the way I understand it, it means that:

• the cache is no longer handled by VPV but by the OS (which is a good thing)
• each time we look at a different image, VPV will read the image from the mmap buffer, which contains the content of the file and not directly the pixels. It means that the image has to be decoded/uncompressed each time. This last point could be problematic in case the decoding is slow. This would prevent high framerate playback which is currently possible thanks to pixel caching.

Also, VPV doesn't need to write back to the pixel buffer (except for the edition feature which we can ignore for now).

[axeldavy]

. Yes . When displaying the data anyway, you need to put it on gpu (where converting the data type is easy and cheap), I don't understand how it is a problem to have the cpu copy of the data being the file content with mmap.

[kidanger]

The problem is having to decode images (from png/tiff to pixel array). Currently the pixel arrays are cached. What you suggest would cache the png/tiff file content. This means that each time we want to display another image, we have to decode it first.

This mmap caching strategy is interesting if we consider that decoding an image is a cheap operation (cheap enough to do it at 30 fps). (In practice, using pyramidal + tiled tiff is the way to go to achieve such performance, but this wouldn't result in a general purpose image viewer.)

I guess this requires testing to see if decoding is too slow for fast playback. Do you see anything else I don't see?

[axeldavy]

I guess it depends of the layout of the images. If the files are just a header + a buffer with all the uncompressed data sequentially, then it's easy to read. I don't know much about the storage of tiff and png, thus I cannot tell how easy it is to decode the files.

[kidanger]

Impossible with current file formats.

[axeldavy]

Yes it is: http://www.simplesystems.org/libtiff/man/TIFFOpen.3tiff.html

There is a mode for memory mapping when tiff format is good enough