[bug] socket implementation slow on slow machine about ueberzugpp HOT 25 CLOSED

Can you test lfub and check if the socket issue is still there? Could be an issue with lobster.

from ueberzugpp.

how do i configure it? When i navigate to an image it sais "binary" and no preview.

from ueberzugpp.

Follow the instructions of #57

from ueberzugpp.

I'm not on wayland.
It still doesn't work, i need to put something in there?

~/.config/lf/preview
~/.config/lf/cleaner

explain a bit better.

from ueberzugpp.

You don't need to be on wayland for it to work. Just copy preview and cleaner to ~/.config/lf and edit the file lfrc with the following content:

set previewer ~/.config/lf/preview
set cleaner ~/.config/lf/cleaner
set drawbox

after that just run lfub

from ueberzugpp.

where are preview and cleaner? I just manually installed the downloaded binary.

from ueberzugpp.

They are here. https://github.com/jstkdng/ueberzugpp/tree/master/scripts/lf

I should add them to the binaries.

from ueberzugpp.

-_- You pulled my teeth one by one. It works now. I just downloaded lfub from the link in the README. You should explain better how to set it up.

However... it's as slow as lobster.

from ueberzugpp.

In ranger, only the first time is slow, it seams to be loading. After that it's plenty fast. On lf however, it's as if it completely reloads each time. Maybe it's just ranger doing something clever?

from ueberzugpp.

beh... even when i move out of a folder, the image is slow to unload.

from ueberzugpp.

Can you check the ueberzugpp logs? Ranger uses the X11 output and it is fast. Maybe lobster/lfub are using another output.

from ueberzugpp.

you mean that? [X11] [info] Canvas created or maybe that [opencv] [info] Loading image they are all the same.

The only difference i can see, is the identifier and there's an error when ranger exits.

from ueberzugpp.

Hmm, is it slow even when using libvips only?

from ueberzugpp.

with this in ~/.config/ueberzugpp/config.json

{
    "layer": {
        "no-opencv":true
    }
}

still the same. All that in X.

from ueberzugpp.

you can't even measure a small difference in performance?

from ueberzugpp.

I've made some performance improvements with the X11 output. If that doesn't help then maybe it could be an issue with your kernel? Perhaps the kernel from debian 11 doesn't perform well when a lot of system calls happen in a short period of time.

from ueberzugpp.

uname -r 5.10.0-23-amd64

beh, no difference. I'll be upgrading to debian 12 in a few days. I still think it's some synchronization issue.

from ueberzugpp.

I don't think so, all synchronization issues have been fixed on X11. Otherwise, sending fast commands would just crash ueberzugpp. Maybe the culprit is that debian 11's gcc compiler doesn't output performant enough binaries. If you have the same problem on debian 12 do reopen this issue.

from ueberzugpp.

i'm on debian 12, the issue is still there.
Because you closed the issue, i can't reopen it.

from ueberzugpp.

Hmm, I'll see what I can do.

from ueberzugpp.

I've made some changes, the socket should be faster now.

from ueberzugpp.

no change. I think you're misdiagnosing the problem.

from ueberzugpp.

pretty much, I've exhausted the possible causes of any slowdowns related to my socket implementation. Unless there's something I'm not taking into account, it could just be that slow pcs are slow.

from ueberzugpp.

the fifo version works fine... A mange reader in python is faster, the ueberzug fork is faster....

from ueberzugpp.

hmm, well, you win some you lose some, keep using the fifo or don't. You are free to do what you want. Unless there's more informacion that can aid in solving this, closing.

from ueberzugpp.