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 (2d27f8db6a19f93529787731b0efa8f001478f6d, 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

  https://user-images.githubusercontent.com/40576902/190554251-4aa55dfa-89d7-47e4-bd58-1733a97af41a.mp4 https://user-images.githubusercontent.com/40576902/190834031-6d47abce-4d5a-41fe-97f2-e1851669c8b8.mp4 https://user-images.githubusercontent.com/40576902/190834843-1d1ed9d2-be76-4c3a-b020-177295779be1.mp4

[Tyriar]

Upstream issue: https://github.com/xtermjs/xterm.js/issues/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