Screen stutters for modern GPU acceleration based terminals like Alacritty, iTerm2, etc; use redraw with NOT_VALID

[poetaman]

Modern GPU based terminals draw the entire frame on redraws. The way to avoid screen from stuttering is to use a different approach to redrawing screen.

The solution is mentioned in neovim/neovim#14225 (comment), and vim/vim#8002 (comment). The solution is to redraw with
NOT_VALID, which would redraw everything but not clear the screen.

This problem is similar to vim on GPU accelerated terminals also has the problem and plans to fix it: vim/vim#8002

Here's an example of screen stuttering in rsclock. I am using tmux with frame sync feature enabled. Steps for enabling sync feature are detailed here: alacritty/alacritty#4904 (comment)

You won't see this problem with traditional terminals that do not use GPU acceleration. Though the future is with terminals that use GPU acceleration -- they are fast.

stutter_rsclock.mp4

As a sidenote, this screen stuttering does not happen in tty-clock (I tried with same setup & within tmux). But it doesn't guarantee all clock instances to update at same time like rsClock seems to (xorg62/tty-clock#70). Great work rsClock on that front!

[valebes]

Thanks @reportaman for the documentation provided.
As soon as I have time I will read the whole thing.
Thanks for the contribution :-) .

[valebes]

Yeah, I can reproduce the issue on Alacritty

[poetaman]

Yes I think this particular quirk of transitioning from coding TUIs that work on old terminal drawing mechanisms to ones that work on both new & old deserves an article on forums like reddit, medium, and hacker news... Given vim too has this problem (neovim doesn't though), shows that even experienced programmers are unaware. Anyway, I am happy to know you could reproduce it.

[valebes]

@reportaman Hi, try to check the latest commit. If is all okay I will proceed to release a new release.

[poetaman]

@valebes Yes, its working well now! No more stutters!!

Here's a video:

clocks.mp4