imv
imv copied to clipboard
Image reloading is relatively slow
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?
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.
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.
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.
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.
I am working on this, btw, in case anyone was planning to do this. Almost done, but will probably need some reviewing.
Sounds good. I started on this, but did very little. I'll review when you open a PR
@eXeC64 this may need a milestone update 😊, hopefully that will attract the attention of somemone actually able to finish this PR.