-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
webgl regression: may not render as typing #4665
Comments
Yesterday, I also discovered this issue in the internal version. One of the two devices had this issue, so I didn't pay much attention The display is only displayed after entering a few characters. |
On Monday, I'll see if the device can still reproduce. 😆 |
|
@tisilent what do you mean by time interval? |
hi @Tyriar.
20230816_174117.mp4
|
Does it go away if you test with an older release, like 5.2.0? From there on it would be good to pin it down to a certain beta build to get a hold of the commits in question. And if much older releases like 5.1.0 still show the glitch, then it might be a good idea to repeat the testing with an older chrome version and/or other webgl capable engine like firefox to rule out engine version issues. |
@jerch I tried two combinations,
|
I can't reproduce this unfortunately |
- New 'trace' log level in the API, you should expect very spammy logs when trace is on and filter them down. As opposed to 'debug' which should be more readable. - @traceCall decorator logs the args and return value of the decorated method. Wecan use this on key functions in various parts of the code to assist debugging issues that are hard to reproduce such as xtermjs#4665. - Decorated a few webgl render methods for xtermjs#4665. - There's an early exit in @traceCall when not on the trace log level so the runtime impact when not in trace is negligable. Part of xtermjs#4665
- New 'trace' log level in the API, you should expect very spammy logs when trace is on and filter them down. As opposed to 'debug' which should be more readable. - traceCall decorator logs the args and return value of the decorated method. Wecan use this on key functions in various parts of the code to assist debugging issues that are hard to reproduce such as xtermjs#4665. - Decorated a few webgl render methods for xtermjs#4665. - There's an early exit in traceCall when not on the trace log level so the runtime impact when not in trace is negligable. Part of xtermjs#4665
https://github.com/xtermjs/xterm.js/assets/48614781/3218fdf8-8ec3-4c33-afe4-10fc1e57188c |
I don't know how to track it at the moment. 😭 |
Well I havent seen the issue once here, but I am still on chromium 112 with my tests (linux here). Which makes me wonder, if the recent WebGPU additions in chromium might have to do with this (maybe the drawing/update cycling got affected by those, temporary context loss, things like that...) |
@deepak1556 we're starting to think this webgl issue might be related to the Electron update |
@tisilent since you can reproduce, could you try it on https://insiders.vscode.dev/github/xtermjs/xterm.js in a recent Chrome version? This will help tell if it's a Chromium problem or an Electron problem. |
Okay, I'll try it later. |
Also tested on Chromium 116 (cheated a bit by using custom chrome binary from newest playwright) - cant repro. Also same output from chrome://gpu as above. If there is a specific pattern to trigger it, I can test it again. What I tested was xterm.js demo (master) and xtermjs.org with switching browser tabs and stealing focus in between. All fine here. |
Also note that in your demo repro video in #4665 (comment) the cursor on the right side still moves & updates on every input, it is just the char glyphs that come up lazy at once. Hmm. |
I saw that fps has fluctuations and is processed, but the characters are not displayed. At first, I checked the code and found that the model output was consistent. This device is Virtualization. emmm. |
Verified, older versions of Chromium will not encounter this issue. |
@tisilent Can you also check, if chrome://gpu --> "Graphics Feature Status" shows significant differences between your tested versions, e.g. WebGPU enabled here but disabled there? My best guess so far - chromium devs did some fundamental rework on the graphics internals with recent versions, mainly to get WebGPU finally shipped. This may include shifts in handling certain driver/gc constellations (moved from HW to SW support, or vice versa, I think they update their blocklists regularily). Also saw only windows reports so far, not sure if its platform related as well. In summary - from xterm.js side there is nothing we can do about that (beside tracking and writing a bug report, if we have enough evidence). |
This hw acc support issue in browsers is really annoying, it pops up every now and then for us. I think that xterm.js is just a surface vector here, where ppl experience it pretty early / more directly, but in fact is a deeper problem with the engine's hardware support. At this point I wonder how other popular canvas/webgl driven libraries handle that issue (like d3, three etc), if there are any best practices to collect issues and report upstream. @tisilent I feel your pain, such a regression is hard to swallow when coming from a flawless working system. If you are really up to find the culprit code change in chromium, I can only suggest to try out the nightly chromium builds one by one until you find the first defective build. From there you can dig deeper into the commits... |
If there is a reliable repro in Chromium browser, then I recommend to use the following bisect tool https://www.chromium.org/developers/bisect-builds-py/ to narrow down the commit range. It will be very useful when filing upstream bug report. |
@jerch There are too many features, some are different..other.. The Graphics Feature Status is the same. |
We looked into this and here's the tracking Chromium bug https://bugs.chromium.org/p/chromium/issues/detail?id=1476475. See microsoft/vscode#191795 for how to workaround this in Electron in the meantime (still needs to be verified once merged). |
Slightly offtopic (still prolly related to chromium's recent work on the graphics internals) - my sixel-bench test yields these fps numbers (on the same machine/system):
Btw chromium started at ~42 MB/s 2ys ago, but the recent drop to 13 MB/s is really hurting. Firefox was always that slow, Webkit is stable at its fast pace. |
Yes something fishy is going on:
Idk the right values for angle, I basically just guessed around, and found an empty value to be the fastest. 🤔 Edit: |
I haven't found a doc for these settings, it was mostly from reading the code https://source.chromium.org/chromium/chromium/src/+/main:ui/gl/init/gl_display_initializer.cc;l=26-170 |
Was finally able to restore the old throughput numbers for the sixel test by disabling vulkan in flags and using the empty Its really astonishing how fragile chrome's graphics settings are, while firefox and webkit didn't change fps numbers at all across different updates. Also I dont have to mess with undocumented switches there. (Note that webkit just added alot of stuff in the graphics section like offscreen canvas and bitmap support...) |
Since this is a browser issue I'm closing this off |
Issue has been addressed in the vulkan backend, refs https://bugs.chromium.org/p/chromium/issues/detail?id=1476475#c14 |
VS Code issue: microsoft/vscode#190195
I think this started happened in the last few weeks. Will need to review recent changes/optimizations to webgl
The text was updated successfully, but these errors were encountered: