Closed poetaman closed 3 years ago
Btw, this also happens when set lazyredraw
option is included in .vimrc
. I searched string redraw
in Startify's repo, and found multiple of them, though don't know which one comes in chain of command :Startify
Also, the problem only occurs with Vim & not NeoVim. I just checked... There is no stuttering with NeoVim in OpenGL GPU-accelerated terminals on :Startify
Opened an issue on Vim, as it happens with plain :redraw!
too. https://github.com/vim/vim/issues/8002
Yup, that's an issue with the editor (only Vim in this case) and nothing I could fix from this plugin.
Thanks for reporting though!
Startify is an awesome launchpad/dashboard not just during start time, but also in the middle of doing things. There is one problem though, opening a startify buffer makes the entire vim screen stutter multiple times in quick succession on modern GPU-based terminal emulators. The same effect does not happen when opening other buffers using usual Vim commands.
Why does this happen? and why does it matter to think differently? Am not a total expert on this, though AFAIK older terminal's relied on partial screen redraw. They would draw only part of the screen that was necessary to be redrawn. So this meant that even if there is some part of the screen that was receiving multiple updates instead of one unified update, it would not cause a flickering/stuttering effect for the entire terminal screen.
On the other hand, modern terminal emulators that offload rendering to GPU, tend to do a complete screen redraw, as redraws are cheap. This works if the program does not issue quick succession of commands that cause redraw, before it settles to final intended screen state. For usual Vim commands, I don't see any stuttering/flickering. But when I open Startify again, it seems to cause stutters.
I reproduced this behavior on all OpenGL/GPU-based terminals: Alacritty, Kitty, WezTerm, iTerm2. But (as expected) this effect is not seen on Apple's in-built Terminal.App (which is an old-style slow terminal). The reason tuning UI to work well on GPU-based terminals is worthwhile is because they are the future (try increasing your system's key repeat rate, and scrolling in old-style vs GPU-based terminals [you wouldn't want to go back]).
Here's an mp4 video that shows the effect I am talking about. In the video I issue usual vim command like
:bp
that redraw just the split &:Startify
(bound to a key on my machine) that is supposed to redraw the split (and by that effect the screen) only once. IMO the stuttering will go away if Startify completes all its work, and then issues a single command to open Startify buffer in the current window. Not sure if this makes sense: but think of it as async jobs/channels. All work happens in background, and it sends update to screen only once. Also, probably something like this could happen if:Startify
internally calls external programs via shell, not sure though.https://user-images.githubusercontent.com/71736629/112261918-f2346580-8c29-11eb-9dcc-9c9c26f54e72.mp4