mirror of
https://github.com/neovim/neovim.git
synced 2024-12-22 20:25:16 -07:00
e598811e76
Avoid clearing the screen in most situations. NOT_VALID should be equivalent to CLEAR unless some external force messed up the terminal, for these situations <c-l> and :mode will still clear the screen. Also eliminate some obsolete code in screen.c, that dealt with that in vim drawing window 1 can mess up window 2, but this never happens in nvim. But what about slow terminals? There is two common meanings in which a terminal is said to be "slow": Most commonly (and in the sense of vim:s nottyfast) it means low bandwidth for sending bytes from nvim to the terminal. If the screen is very similar before and after the update_screen(CLEAR) this change should reduce bandwidth. If the screen is quite different, but there is no new regions of contiguous whitespace, clearing doesn't reduce bandwidth significantly. If the new screen contains a lot of whitespace, it will depend of if vsplits are used or not: as long as there is no vsplits, ce is used to cheaply clear the rest of the line, so full-screen clear is not needed to reduce bandwith. However a left vsplit currently needs to be padded with whitespace all the way to the separator. It is possible ec (clear N chars) can be used to reduce bandwidth here if this is a problem. (All of this assumes that one doesn't set Normal guibg=... on a non-BCE terminal, if you do you are doomed regardless of this change). Slow can also mean that drawing pixels on the screen is slow. E-ink screens is a recent example. Avoiding clearing and redrawing the unchanged part of the screen will always improve performance in these cases. |
||
|---|---|---|
| .. | ||
| api | ||
| autocmd | ||
| clipboard | ||
| cmdline | ||
| core | ||
| eval | ||
| ex_cmds | ||
| fixtures | ||
| insert | ||
| legacy | ||
| lua | ||
| normal | ||
| options | ||
| plugin | ||
| provider | ||
| shada | ||
| spell | ||
| terminal | ||
| ui | ||
| viml | ||
| helpers.lua | ||
| preload.lua | ||