Visual glitches in linux console.

[GeorgMeore]

Steps

use add-highlighter global/ number-lines -relative
Open file in linux tty and start scrolling with j and k.

Outcome

Visual glitches.

[GeorgMeore]

Without -relative everything seems fine.

[mawww]

This would indicate the linux console renders every intermediate state instead of what most terminals do: render once there is no more terminal output pending. Its unfortunate because it means the current code that optimize for the amount of data on the wire leads to this flickering.

The linux console is a pretty important use case, even if I rarely use it, I think it is important for Kakoune to be comfortably useable there. To fix this we can either add an option to disable the use of scrolling optimizations or just remove them altogether.

[evanrelf]

FWIW I get the same flickering in the kitty terminal in tmux on macOS. It seemed to show up after I moved to the latest release, and it went away after disabling relative line numbers.

[valpackett]

Just encountered something like that in wezterm. To be clear, do these glitches (both linux console and kitty) look like one frame is rendered with some lines in the middle skipped, or is this something different?

[valpackett]

Interesting comment from Wez re: this happening in modern terminal emulators: wez/wezterm#1128 (comment)

So, I'll try changing 428ddeb to emit the new de-facto standard sync sequences (that are supported by iTerm2 too now). I think these new sequences should avoid the "Synchronized output does not work well with various terminals (including the linux console)" problem? (i.e. Linux console should ignore them?)

[wez]

Let's copy in @christianparpart who has been pushing/tracking the new sync sequence as well in case he has any additional insights/recommendations!

[valpackett]

I can confirm that using the new (supported in wezterm) escape sequences did fix the problem, without the whole pessimization done in b3a1017 :)

@mawww please consider re-applying the cool optimizations but only when the terminal supports synchronization (it can be queried with DECRQM as described in https://gist.github.com/christianparpart/d8a62cc1ab659194337d73e399004036) and it is enabled (and with new sequences it can and should be on by default)

[mawww]

@unrelentingtech Unfortunately this will not be enough to fix the linux console which does not seem to support any kind of synchronization. I guess the choice we have is either to have the nice scrolling optimizations (which will detect line deletions and scrolling) or to ensure no flickering on linux console. I have been trying to see if there is any way to have the scrolling optimization while avoiding intermediate states with lines at a wrong locations, but could not come up with any satisfying solution.

This mostly happens with relative line numbers so an alternative would be to just say that linux console will flicker with that setting.

[valpackett]

I mean, if you do it conditionally — the Linux console would not report support for the new sync, so the unoptimized codepath would be used on it.

[mawww]

Sounds like a nice approach, I'll see how it goes (my main concern is the added code complexity if we really need two separate code path)

[christianparpart]

I am not sure this will necessarily lead to duplicate code paths IMHO. But i am glad to see more software taking advantage of the synchronized output feature. :-)

[lenormf]

Dupe of #3429 ?

[mawww]

@unrelentingtech Implemented opt-in behaviour to the smart diff based screen update if terminal_synchornized is set, now that we use a DECSM/DECRM sequence we can actually opt-in even if the terminal does not actually support synchronization and still get less terminal traffic.

I intend to use DECRQM eventually to set the default for that behaviour.