Timeline for Why do terminal emulators still have screen flicker?
Current License: CC BY-SA 4.0
20 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 5, 2018 at 13:49 | comment | added | Lassi |
The reset command is slow because it deliberately sleeps for a second to allow old hardware terminals some time to catch up. So that's a completely different issue. See Why does the reset command include a delay? (unix.stackexchange.com/questions/335648/…) for a great discussion. AFAIK the clear command doesn't sleep deliberately.
|
|
| Nov 24, 2018 at 14:21 | history | edited | Lassi | CC BY-SA 4.0 |
asciinema video doesn't show scrolling artifact
|
| Nov 24, 2018 at 14:03 | vote | accept | Lassi | ||
| Nov 24, 2018 at 13:46 | comment | added | Lassi | Also, check this out: superuser.com/questions/1195103/… According to a book on the subject "On Linux, the pseudoterminal capacity is about 4 kB in each direction". If the buffer is really so small even on current kernels, no wonder there are so many artifacts! Big full-screen updates ought to exceed that limit on the regular. | |
| Nov 24, 2018 at 13:24 | comment | added | Lassi | The fundamental problem is that the application/curses library knows exactly what bunch of ANSI codes constitutes one screen, but this information is lost when it writes out the codes to the terminal because there are no codes for delimiting a screenful of stuff. So the terminal emulator has to guess when to update the screen. The synchronized updates proposal aims to add the appropriate codes so the information is not lost and the emulator doesn't have to guess. | |
| Nov 24, 2018 at 12:49 | comment | added | Lassi |
@JdeBP Sure, but the effect I see on just about every terminal emulator I've ever used looks identical to the effect seen in that asciinema video. And the probable cause (the terminal emulator updates the screen in several steps because a screenful of text/ANSI is so much data that it takes several read() and write() cycles) is logical. Unless asciinema renders differently in different web browsers, but the effect in the asciinema video looks exactly like a terminal artifact (cursor motion / screen tearing), not like any kind of browser artifact.
|
|
| Nov 24, 2018 at 12:40 | comment | added | JdeBP | A related question is unix.stackexchange.com/questions/383218 . | |
| Nov 24, 2018 at 12:40 | comment | added | JdeBP | asciinema is not necessarily representative of how any particular terminal emulator works, as the rendering procedures are not necessarily the same. | |
| Nov 24, 2018 at 12:07 | comment | added | egmont | @mosvy Yeah you're probably right about the framebuffer being the culprit. | |
| Nov 24, 2018 at 10:05 | comment | added | Lassi | That screencast is also a good demonstration because the zoom is somewhat jerky (maybe the user pauses between presses of the zoom key, or map rendering takes a while, etc.), but that's not the effect I'm talking about. It would be nice if everything were instantaneous but that's not always possible due to network and processing delays. What I think can be done is to eliminate nearly all flicker by adopting the escape codes in that synchronized updates spec. | |
| Nov 24, 2018 at 9:48 | comment | added | Lassi | I think I found a screencast where the effects are reproduced reliably: asciinema.org/a/117813 after 00:15. The effects are visible cursor movement and tearing (en.wikipedia.org/wiki/Screen_tearing) while the screen update is in progress. @egmont also found a technical proposal that should solve the problem: gitlab.com/gnachman/iterm2/wikis/synchronized-updates-spec | |
| Nov 24, 2018 at 1:54 | answer | added | egmont | timeline score: 5 | |
| Nov 24, 2018 at 1:40 | comment | added | user313992 | @egmont You're probably talking about the framebuffer console on linux, not about the vga 80x25 text mode. | |
| Nov 24, 2018 at 1:32 | comment | added | egmont | @mosvy "Try the vga text mode console" – The vga text mode console is about 2 magnitudes slower than graphical emulators when processing large amount of data, I guess because it updates the contents inside the video card's area after every incoming chunk received. It becomes blazingly fast if you switch to another VT. | |
| Nov 23, 2018 at 23:55 | comment | added | Lassi | I think part of the slowness is that recent GUI terminal emulators draw antialiased (and vector-based?) fonts onto a window, blurring and rasterizing each character every time it's drawn although that's not necessary when drawing a monospace font onto a solid-color background. But that's bitmap rendering slowness. I'm wondering why the screen is updated in several steps. E.g. if you open a menu in a GUI application, it doesn't draw half the menu items, then show them, then draw the other half. It shows the entire menu at once so you don't see any flicker. | |
| Nov 23, 2018 at 23:47 | comment | added | user313992 |
I find all the framebuffer consoles and terminal emulators that come bundled with "modern" desktop environments (gnome-terminal, etc) unbearably slow. I didn't even suffer to use them long enough to notice any flicker ;-) Try the vga text mode console or mlterm on a plain Xorg display. And also set xset r rate 200 200 for good measure ;-)
|
|
| Nov 23, 2018 at 22:54 | comment | added | Lassi | Nope, I think I've seen this on I every PC I've ever used terminal emulators on. Right now I get it on all terminal emulators I have installed on MacOS as well as consoles on Linux and FreeBSD virtual machines. It may not be apparent unless you know what to look for, but the main effect is that the cursor movement between updates is clearly visible (the terminal control language is like "move cursor to (y,x), then write the following text, etc.) This cursor movement looks like blinking or flicker when you aren't observing in detail. | |
| Nov 23, 2018 at 21:45 | comment | added | Chris Davies | I don't see any slowness, even on truly remote xterm style windows. Are you using particularly old or slow hardware? | |
| Nov 23, 2018 at 21:40 | review | Close votes | |||
| Nov 24, 2018 at 18:41 | |||||
| Nov 23, 2018 at 21:17 | history | asked | Lassi | CC BY-SA 4.0 |