Terminal: Issue with GPU acceleration and clearing ANSI formatting

[elsandosgrande]

Type: Bug

When using ANSI escape sequences to format the input of a C++ program as seen in the terminal and then clear that formatting before the next input prompt, if there is more than one such prompt anywhere in the program, seemingly regardless of anything else, the background formatting will “spill over” into the blank whitespace past \e[0m until the end of the next line, that is the right edge of the integrated terminal, except for any text, including spaces, that may be on that line, which is either unformatted or has its own formatting.

This issue occurs with GPU acceleration set to either WebGL or 2D canvas, but not when it's disabled. This issue, oddly enough, also occurs in GNOME Terminal , but not XTerm. Note that XTerm gives incorrect colors with two colons after 38:2 and 48:2, but the integrated terminal does so when there is only one, so they are in direct conflict unless one wants to just swap all of the colons for semicolons.

Yes, this is reproducible with all of the extensions temporarily disabled.

Here's a minimal test case:

#include <iostream>

using namespace std;

int main() {
    int one, two, three;

    cout << "Test one: \e[38:2::15:80:252;48:2::189:252:242m"; cin >> one; cout << "\e[0m"
         << "Test two: \e[38:2::15:80:252;48:2::189:252:242m"; cin >> two; cout << "\e[0m"
         << "Test three: \e[38:2::15:80:252;48:2::189:252:242m"; cin >> three; cout << "\e[0m\n"

         << "Variable one: \e[38:2::102:51:153;48:2::255:240:245m" << one << "\e[0m\n"
         << "Variable two: \e[38:2::102:51:153;48:2::255:240:245m" << two << "\e[0m\n"
         << "Variable three: \e[38:2::102:51:153;48:2::255:240:245m" << three << "\e[0m\n" << endl;

    cout << "Test four: \e[38:2::15:80:252;48:2::189:252:242m"; cin >> one; cout << "\e[0m\n"
         << "Test five: \e[38:2::15:80:252;48:2::189:252:242m"; cin >> two; cout << "\e[0m\n"
         << "Test six: \e[38:2::15:80:252;48:2::189:252:242m"; cin >> three; cout << "\e[0m"

         << "Variable four: \e[38:2::102:51:153;48:2::255:240:245m" << one << "\e[0m\n"
         << "Variable five: \e[38:2::102:51:153;48:2::255:240:245m" << two << "\e[0m\n"
         << "Variable six: \e[38:2::102:51:153;48:2::255:240:245m" << three << "\e[0m" << endl;

    return 0;
}

VS Code version: Code - Insiders 1.72.0-insider (2d27f8d, 2022-09-08T05:16:43.841Z)
OS version: Linux x64 5.17.0-1016-oem
Modes:
Sandboxed: Yes

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-1035G1 CPU @ 1.00GHz (8 x 3370)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: disabled_software video_encode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	2, 1, 1
Memory (System)	7.54GB (0.58GB free)
Process Argv	--disable-extensions --crash-reporter-id d4a87075-f287-413a-9896-114353df682c
Screen Reader	no
VM	0%
DESKTOP_SESSION	ubuntu
XDG_CURRENT_DESKTOP	Unity
XDG_SESSION_DESKTOP	ubuntu
XDG_SESSION_TYPE	wayland

Extensions disabled

A/B Experiments

vsliv695:30137379
vsins829:30139715
vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30422396
pythontb:30258533
pythonptprofiler:30281269
vshan820:30294714
pythondataviewer:30285072
vscod805cf:30301675
bridge0708:30335490
bridge0723:30353136
cmake_vspar411cf:30557515
vsaa593:30376534
pythonvs932:30404738
cppdebug:30492333
vscaac:30438845
pylanb8912:30522163
vsclangdf:30492506
c4g48928:30535728
dsvsc012:30540252
pylantcb52:30558418
vscccc:30564267

---

Edit

So… Somehow, as I was writing this bug report, the issue seems to have almost completely gone away, except if I close VS Code and then reopen it. Maybe it has something to do with terminal sessions being restored somehow? I have screenshots of the issue occurring outside of the minimal test case earlier which I can share if need be, but, for now, I'll just share one screenshot of the test case. Note that the issue occurred in both test rounds (test one, two, three/test four, five, six) earlier.

Edit two

So, it seems that running clear before running the minimal test case makes the issue completely go away somehow. Bizarre.

Edit three

It seems like the same inconsistent behavior is shared by GNOME Terminal. I've just been putting the laptop to sleep instead of rebooting it for the past few days now, thinking that I might come across whatever is causing this unexpected inconsistency,

Edit four

Correcting a typo in the background segment of the ANSI code in the first test round (test one, two, three): 48::2:[RGB value] → 48:2::[RGB value]

Edit four

I'm still doing some testing on the method to recreate this after running clear — running the minimal test case several times in a row after running clear seems to do it, but I still need to get a grasp on exactly how many times and also do some more reproducibility testing — but here's a screenshot with the typo fix from above which is a better showcase of the issue. Software rendering seems to be affected as well, but to a much lesser extent, given that only the cursor is colored in and only in the first test round, test three to be specific.

Edit five

Here's a screen recording of the aforementioned minor issue with software rendering. I'm also renaming “Screenshots” to “Media” now.

Edit six

Running the script below, I've determined that the number of runs it takes before the issue appears after running clear is four in XTerm and XTerm.js and three in GNOME Terminal:

clear; declare -i i=0
while true; do
~/Projects/C++\ study/test
i=i+1
echo -e "\n\nRun number \e[91m"${i}"\e[0m\n\n"
done

Edit seven

OK… So… This is the weirdest thing I've ever seen. Just holding down Enter leads to reproducing the issue. Screen recording attached. Oh, also, it seems that the software rendering issue with the cursor outlined in edit four is definitely related to this issue, since holding down Enter for long enough when the terminal is set to software rendering yields a cursor with a colored-in background. Since there seems to be something causing both rendering modes to glitch out to various degrees, this ticket could probably use a new title. I can't think of one though 😅

Edit eight

So… After testing in all three terminals, it seems like the rendering goes haywire as soon as the terminal has to scroll because the number of lines held in memory exceeds the number of lines that can be displayed in a given window, at least when just holding Enter down. Screen recording attached.

Media

2022-09-16.05-34-00.mp4

2022-09-17.02-45-01.mp4

2022-09-17.03-14-28.mp4

[Tyriar]

Upstream issue: xtermjs/xterm.js#4120

[elsandosgrande]

Do I provide any further information, for example if I figure out why clear makes the issue go away, in this issue, or in the upstream issue?

[elsandosgrande]

Speaking of further information, I think I might've figured out how to trigger it reliably after running clear, but I'll do some more testing just to be sure whilst I await a response to my earlier question. Also, I can also replicate it on XTerm with that.

Given that it's present on seemingly every terminal I've tried except for XTerm.js with software rendering, could it be a more general GPU rendering issue as opposed to being limited to XTerm.js alone?

---

Edit

In the three hours since I wrote this comment, I've decided not to wait for a response before adding anything new to this issue, since I want to share the additional information as soon as possible and then get on with the rest of my day. If need be, I'll share the information in the upstream issue ticket as well.

[MelleNooijen]

CR, macOS 12.6 (Darwin arm64 21.6.0) running VS Code 1.71.2 (universal)

Edit: Can also reproduce colour error with cursor described in "Edit four".

[Tyriar]

Fixed upstream