Single character updates not always rendered consistently in Chromium / Chrome

[oddjobz]

Note

Demonstrable on xtermjs.org main page!

Details

• Google Chrome Version 114.0.5735.133 (Official Build) (64-bit) [also current Chromium]
• Linux / Ubuntu 22.04
• xterm.js version: 5.2.1

Steps to reproduce

1. visit xtermjs.org in browser
2. click in black terminal window next to "$" prompt
3. press "1", it is not echoed but the cursor moves to the right
4. press "1" a second time, the 1 appears as does the missing 1 to give "11"
5. press "1" another 5 times, no echo, but the cursor moves to the right
6. press "1" once more and a new 1 is echoed, and the missing 5 "1"'s appear
7. backspace over the characters and try again, seems to work fine
8. Same issue is present in my application that uses xterm.js

Interestingly this seems to work fine in Firefox .. so I'm randomly guessing this is a "webgl" issue (?)

[roussieau]

If I launch chrome with --disable-webgl, it "works" again.

[jerch]

Hmm, can you run the demo of the base repo? To get it up, just do git clone ... && cd xterm.js && yarn && yarn start, then point the browser to http://localhost:3000. In the demo there you can switch through the renderers and other settings.

Crucial questions:

• Does this only happen with webgl renderer? If so, maybe switch to canvas/DOM as a hotfix for your app.
• Does this only happen with Chrome 114? What about older Chrome versions? Firefox? (--> if with other versions too, most likely xtermjs bug)
• Does this happen on other machines with different GPU setup as well for Chrome 114? (--> if so, most likely a Chrome bug)

I cannot repro it myself, but I am still on v112 here (Ubuntu, tested both Intel graphics and nvidia GPU).

[oddjobz]

If I launch chrome with --disable-webgl, it "works" again.

Ok, so maybe it was an educated guess ... ;-)

[oddjobz]

Hmm, can you run the demo of the base repo?
Crucial questions:

• Does this only happen with webgl renderer? If so, maybe switch to canvas/DOM as a hotfix for your app.

Yes, reverting to "canvas" looks good, performance seems fine.

• Does this only happen with Chrome 114? What about older Chrome versions? Firefox?

Don't have an older chrome, but Firefox does not exhibit the problem.

• Does this happen on other machines with different GPU setup as well for Chrome 114?

Again, don't have easy access to another GPU, but given it's 10s on the xterm.js homepage and I'm using the current stock Ubuntu and Chrome, someone will be able to test this with no effort. I would be inclined to say that this is a chrome Bug as it only appears to happen on one version of Chrome and not firefox and it appears to be just WebGL. The issue I guess is that if it's just in the latest Chrome, it's a regression issue which will affect more users as they upgrade.

I cannot repro it myself, but I am still on v112 here (Ubuntu, tested both Intel graphics and nvidia GPU).

Just for the record I'm using an NVIDIA GT710.
I'm happy using "canvas" as a fix, but if Chrome doesn't fix the issue it may be an issue moving forward for anyone who relies on WebGL.

[jerch]

... given it's 10s on the xterm.js homepage and I'm using the current stock Ubuntu and Chrome, someone will be able to test this with no effort.

True, we need a bigger test base and its quite easy to check via the xtermjs homepage. @Tyriar Do you happen to have ppl with Linux machines in your team with different distros/GPU-setups, that would be able to check that with a v114 Chrome/Chromium?

I would be inclined to say that this is a chrome Bug...

Yes it seems so, but it is still not clear, if this is not caused by subpar packaging. Chrome/Chromium is quite a fat piece of software (LOC-wise it accounts as its own OS already), and I think there is quite some customization for Ubuntu/Debian going on. Things like selinux/apparmor might have a saying here too for snap or appimage packages (Can the GPU access be limited by those? no clue). Or X11 with its driver nightmare, and pretty much the same for wayland...

To get more insights:

• Whats your distro? --> Ubuntu 22.04
• Whats your GPU setup? --> nvidia GT710 - Is this GPU fully supported by installed drivers? With recent enough OpenGL support?
• Do does issue go away with intel integrated graphics? (Would be a bold hint towards driver issues with the kinda old nvidia GPU, or lacking features chrome expects to find on the GPU/OpenGL...)
• Whats your display system, X11 or Wayland?
• What type of package do you use? deb or snap or anything else?
• If you start chrome at the cmdline - are there any access or permission failures/warnings?
• Do you have selinux or apparmor enabled?

Idk if you want to go even further, the next steps would be to debug webgl settings in chrome itself and compare them with an older still working version.

---

Edit:
Just checked chrome release changes (see here) - it seems they activated WebGPU by default since v113, so there were def. some changes around GPU stuff. I wonder if the weird behavior reverts, if you disable WebGPU?

Edit2:
Maybe thats related - https://bugs.chromium.org/p/chromium/issues/detail?id=1453988?

[oddjobz]

Does this help?

• Display type is X11 .. Chrome package is "apt", chromium build is;
• Version 114.0.5735.106 (Official Build) snap (64-bit) - also shows the problem.
• Opening on CLI, nothing for Chrome, Chromium;
  libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
• SeLinux, no, apparmour, whatever is default on Ubuntu .. I vaguely thought it was standard now (?)

Graphics Feature Status

• Canvas: Software only, hardware acceleration unavailable
• Canvas out-of-process rasterization: Disabled
• Direct Rendering Display Compositor: Disabled
• Compositing: Software only. Hardware acceleration disabled
• Multiple Raster Threads: Enabled
• OpenGL: Disabled
• Rasterization: Software only. Hardware acceleration disabled
• Raw Draw: Disabled
• Video Decode: Software only. Hardware acceleration disabled
• Video Encode: Software only. Hardware acceleration disabled
• Vulkan: Disabled
• WebGL: Software only, hardware acceleration unavailable
• WebGL2: Software only, hardware acceleration unavailable
• WebGPU: Disabled

Problems Detected

• WebGPU has been disabled via blocklist or the command line.
• Disabled Features: webgpu
• Accelerated video encode has been disabled, either via blocklist, about:flags or the command line.
• Disabled Features: video_encode
• Gpu compositing has been disabled, either via blocklist, about:flags or the command line. The browser will fall back to software compositing and hardware acceleration will be unavailable.
• Disabled Features: gpu_compositing

[jerch]

Oh well - all hardware acceleration is disabled for you? How come? Maybe they have raised the needed OpenGL version/flags? Would that change with an older chrome version? Any chance to get it running with HW support? Is Firefox using hardware acc? I wonder how you can even browse fat websites these days with only SW support, isnt that sluggish as hell?
(On a sidenote: HW acceleration still works with my >10ys old laptop with a GeForce GT 525M.)

Thats a really interesting outcome, and even may point to some faulty software shim. And sorry for so many questions.

---

Btw w'o hw GPU support in the browser the canvas renderer is your best choice - its still reasonable fast compared to the DOM renderer. I am really astonished, that the webgl renderer is working at all for you and not failing during allocation.

[oddjobz]

:) Well (!) my machine seems to work fine, and the desktop tools all point to WebGL, Vulkan etc all working / being available. Now on Googling, I came across a site that appeared to be powered by ChatGPT that offered the following code snippet to test for 'actual' availability (my output included);

const canvas = document.createElement('canvas');
const context = canvas.getContext('webgpu');
if (!context) {
  console.error('WebGPU is not enabled');
} else {
  console.log('WebGPU is enabled');
}
VM78:6 WebGPU is enabled

Now, maybe I've inadvertently inhaled something I shouldn't, however it kinda looks like it's available (?) So is ChatGPT wrong and this isn't a valid test, or is chrome://gpu also ChatGPT powered and hallucinating? I'm still looking, there seems to be a disconnect somewhere between the driver and Chrome ...

My NVidia settings seem to show lots of what look like accelerated features for GLX, OpenGL / EGL.

CUDA Cores:    192
Memory:        2048M
Link Speed:    5.0 GT/s
...

[oddjobz]

Mm, double checked this with my "chromium" installation just to make sure I'm not going mad. If I run "google-chrome --enable-gpu", then go into "chrome:flags" and set "Override software rendering list", then re-launch, I get full hardware acceleration. So for some reason, my hardware configuration seems to be unsupported and as a result hardware acceleration is blocked by default on chrome and chromium browsers (!)

[Everything I have, to me, is pretty standard, if you want a cheap / fanless performant GPU, a GT 710 takes some beating]

Now I have hardware acceleration, the problem seems to have evaporated, so it looks like there is a WebGPU emulation layer in Chrome which gets activated when there is no hardware acceleration. And, it rather looks like it has a bug that affects xterm.js. Well, that's my best guess anyway.

So webgl now working, however looking at the implications I think you're right, best stick to 'canvas' :-)

[jerch]

... it looks like there is a WebGPU emulation layer in Chrome ...

Chrome has a software rasterizer, which imho can emulate WebGL. Not sure how complete that is, and whether it can handle WebGL2 and WebGPU. (WebGPU is a pretty new more direct GPU-API, and not based on OpenGL anymore)

I think you have found a bug or a race condition in that software emulation here. Still the webgl renderer in xtermjs is in fact webgl2, so this might explain the partial dysfunctionality, if the emulation does not the full webgl2 deal.

So for some reason, my hardware configuration seems to be unsupported and as a result hardware acceleration is blocked by default on chrome and chromium browsers

Imho thats a known issue with chromium, it maintains a blacklist for faulty driver/device combinations found in the system and thus may switch off the acceleration. There are some tricks to force it into using hardware acceleration, but that differs a lot between archs / driver versions / GPU model. So while you might be able to resolve the issue once, it just might occur again after the next driver update.

Closing the issue, as it seems not related to xtermjs at all.