imv icon indicating copy to clipboard operation
imv copied to clipboard

Image reloading is relatively slow

Open rien333 opened this issue 4 years ago • 7 comments

When compared to sxiv, which uses inotify to monitor file changes, imv reloads images relatively slow. Apparently it polls the current file path every second or so. I believe inotify was swapped out because of #67, making imv less linux specific.

Nothing wrong with cross-platform support, but the current implementation is bit eh compared to the possibilites of inotify. First of, the method that uses stat is more resource intensive. This might be partly why sxiv shows 0% cpu usage (to be expected from a simple image viewer), while imv can show up to 1% on my machine. Nothing too bad, but given that I always have imv running, a simpler file change monitoring solution is definitely something I would benefit from. And secondly, the current method is obviously considerably slower (sxiv is pretty much instantaneous on file changes).

Would it be possible to optionally configure imv to be build with inotify for systems that have it available? That way, cross-platform support can be retained, and linux users can gain a bit of speed and freed resources. Shouldn't be extremely hard given that inotify was apparently once supported and sxiv also has code for it. Looking at #67, using the best option available was once intended I think?

rien333 avatar Aug 05 '19 12:08 rien333

If I checkout d0b041f17c34fc36fc8121cfe23e2da2b79cf4fa (the last commit before inotify was dropped) , reloading is instantaneous. CPU usage is still a little high though (but maybe a tiny bit better?), so maybe inotify is not related to that.

rien333 avatar Aug 05 '19 13:08 rien333

Alternatively, some image viewers supports quick reloading by handling some kill signal. This would be fine for my use case (an album art viewer that reloads quickly on song change). I could even submit a PR for this, I already have a sort of hacky solution.

rien333 avatar Aug 06 '19 12:08 rien333

Using inotify inside of #ifdef __linux__ sounds reasonable enough to me. I'd rather opt-in to platform specific features where supported than use signals as a hack, so long as the current approach remains as a fallback for BSDs etc.

This is something to go into the v4 branch I've been casually working on recently, which is a fairly big refactor of imv.

eXeC64 avatar Aug 07 '19 00:08 eXeC64

All the major work for v4 is done, so I'd like to start doing the final clean up to prepare it for release. Therefore I'm afraid I'm pushing this improvement to v4.1.

eXeC64 avatar Aug 19 '19 21:08 eXeC64

I am working on this, btw, in case anyone was planning to do this. Almost done, but will probably need some reviewing.

rien333 avatar Nov 23 '19 18:11 rien333

Sounds good. I started on this, but did very little. I'll review when you open a PR

eXeC64 avatar Nov 23 '19 18:11 eXeC64

@eXeC64 this may need a milestone update 😊, hopefully that will attract the attention of somemone actually able to finish this PR.

rien333 avatar May 08 '21 13:05 rien333