Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preview delay #1824

Open
veganomy opened this issue Nov 1, 2024 · 4 comments
Open

Preview delay #1824

veganomy opened this issue Nov 1, 2024 · 4 comments

Comments

@veganomy
Copy link

veganomy commented Nov 1, 2024

Can we get preview delay in milliseconds? When I traverse through the directory list (by holding j or k), lf seems to speedrun previews of all directories. This is even worse when it's huge text files and database textual files. My CPU / GPU roars when I do this.

@joelim-work
Copy link
Collaborator

The best thing I can think of is to add a small sleep in your previewer script.

The way previewing works is that all the files being scrolled through are added to a queue, which is then processed by a separate thread. That thread runs in a while loop, and during each iteration it pops as many items from the queue as possible but only displays the last item, so slowing down that thread should cause more items to be bunched up together and skipped.

@veganomy
Copy link
Author

veganomy commented Nov 2, 2024

@joelim-work I don't have a previewer. It's mainly directory previews & text previews that are not related to previewer at all.
The continuous listing of directories and accessing of text files by themselves is hurting the resources.
My server is an old rasp pi which runs on 1Ghz & an EMMC storage. I mostly never use it. But when I do, even using lf seems to be resource intensive, considering it to be the most lightweight.

That's why lf needs a dedicated preview delay, because lf already does it on directories and text files.

I could disable preview altogether. But that's like not going to school because I fail in exam.

@joelim-work
Copy link
Collaborator

I had a look at the code - in the case of directories, lf receives a continuous stream of j key events when it is pressed and held, and this ends up launching a separate goroutine to load the corresponding new directory for each key event:

lf/nav.go

Lines 498 to 506 in dda8e88

go func() {
d := newDir(path)
d.sort()
d.ind, d.pos = 0, 0
if gOpts.dirpreviews {
nav.dirPreviewChan <- d
}
nav.dirChan <- d
}()

It looks like this is by design though, perhaps it was done that way so that every directory would get populated into the directory cache (nav.dircache).

@veganomy
Copy link
Author

veganomy commented Nov 2, 2024

That's unfortunate. Currently I'm half jumping (ctrl+d/u) in order to avoid preview bombing. Then I find my needed selection with find (f) & the first charcter.
If there was a delay for previewing, I could've naturally traversing instead of the other way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants