Easy to overshoot when skipping

[hpjansson]

I noticed that when skipping around in the input file, vic can lag well behind my keyrepeat, so when I let go of the key, it will keep skipping for a long time as it's processing the buffered input.

I see two potential ways this could be remedied:

• Eat all the repeated key inputs, then skip a single time. I.e. if you see 'lll' in the input buffer, have it produce just a single skip.
• Same as above, but add up the skips in the input buffer. So if you see 'lll', skip three times in a single go.

[wong-justin]

Sorry, I should've responded to this earlier.

To exaggerate this lag on fast computers: use a large high-res video, set DOWNSCALE_FACTOR in main.rs to 1.0, and maybe use a large output width like -w 999 with a smaller terminal emulator font size.

(The current workaround, to prevent needing to hold l so much, is to jump to 10%-intervals of the video by pressing 0, 1, ... 9 like YouTube.)

---

This is part of a larger issue of UI unresponsiveness. Slow background tasks (mainly just ffmpeg -ss in _create_decoding_process()) currently block UI updates (and input handling) which feels bad and sometimes even eats inputs. For example, on a heavy video, sometimes I press l then q but q never happens.

Originally, I thought of separating slow background functions from UI functions by using an async library. But I'd rather not introduce a heavy dependency and runtime if it's not necessary.

I think I can keep the UI responsive by moving ffmpeg-dependent functions to a second thread, which would in turn tell the UI when each slow task is finished. It would behave like how typical GUI video players show a buffering icon until slow tasks (e.g. network requests) finish, with the UI remaining unblocked and receiving inputs in the meantime.

I haven't written much concurrent code before, so I'm not entirely sure about tradeoffs and implementations (message passing, std::sync::mpsc, callbacks, Arc?), but I think this is the way.

But I should probably implement your simpler input buffer solution first since I've been dragging my feet on these other ideas.

[hpjansson]

Don't worry. I know things take time, and there are many competing priorities in life.

The solution makes sense to me, I'd go for the simple fix first and then implement a cancellable babysitter for the ffmpeg subprocess in the longer term. I don't know what the best approach would be in Rust. In C/GLib I'd just watch the terminal I/O and ffmpeg pipes from the main loop.