diff options
author | Björn Linse <bjorn.linse@gmail.com> | 2018-10-20 23:43:47 +0200 |
---|---|---|
committer | Björn Linse <bjorn.linse@gmail.com> | 2018-10-22 11:59:02 +0200 |
commit | e598811e76a4ee6666b680545097fb06b0ba59aa (patch) | |
tree | 73553d90c1c010bcbe0e8cfef6edf97c61e671be /src/nvim/ex_getln.c | |
parent | 565bbd1485a4c884dbfdb65b8b1c04a0c5da6b3e (diff) | |
download | rneovim-e598811e76a4ee6666b680545097fb06b0ba59aa.tar.gz rneovim-e598811e76a4ee6666b680545097fb06b0ba59aa.tar.bz2 rneovim-e598811e76a4ee6666b680545097fb06b0ba59aa.zip |
ui: disable clearing almost everywhere
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.
Diffstat (limited to 'src/nvim/ex_getln.c')
-rw-r--r-- | src/nvim/ex_getln.c | 9 |
1 files changed, 1 insertions, 8 deletions
diff --git a/src/nvim/ex_getln.c b/src/nvim/ex_getln.c index f40131177e..19a52c913a 100644 --- a/src/nvim/ex_getln.c +++ b/src/nvim/ex_getln.c @@ -214,8 +214,6 @@ static int hislen = 0; /* actual length of history tables */ /// user interrupting highlight function to not interrupt command-line. static bool getln_interrupted_highlight = false; -static bool need_cursor_update = false; - #ifdef INCLUDE_GENERATED_DECLARATIONS # include "ex_getln.c.generated.h" @@ -3020,8 +3018,6 @@ void cmdline_screen_cleared(void) } line = line->prev_ccline; } - - need_cursor_update = true; } /// called by ui_flush, do what redraws neccessary to keep cmdline updated. @@ -3481,10 +3477,7 @@ static void cursorcmd(void) if (ccline.redraw_state < kCmdRedrawPos) { ccline.redraw_state = kCmdRedrawPos; } - if (need_cursor_update) { - need_cursor_update = false; - setcursor(); - } + setcursor(); return; } |