Rendering issues with webgl and ligatures

[LabhanshAgrawal]

Details

• Browser and browser version: Chrome 89
• OS version: macOS catalina
• xterm.js version: At commit 376b29673ba174934b1b6339ef3eed8449fec529

Steps to reproduce

Happened to me using the demo with zsh with powerlevel10k Comparing canvas vs webgl with ligatures

Canvas

Webgl

Below, I'm using suggestions and syntax highlighting plugins for zsh It's suggesting === (untyped part of the suggestion should be in gray)

On typing = Both

On typing == Canvas

Webgl

On typing === Canvas

Webgl

Looks like remnants of earlier paint are there in webgl

[Tyriar]

The grey = is tracked in https://github.com/xtermjs/xterm.js/issues/3288, not sure what's happening with the :, what font is this?

[LabhanshAgrawal]

Fira Code It's the demo running without any changes (just turned on ligatures & webgl and opened zsh)

[LabhanshAgrawal]

It looks like the character from inside the cursor is staying on.

[Tyriar]

It looks like the character from inside the cursor is staying on.

I think that's actually ideal imo, but I don't use ligatures so not 100% sure. The dom renderer is a little bad atm since the cursor highlights all chars in the ligature.

[LabhanshAgrawal]

what I meant was that the artifact for character inside the cursor is left even after typing and the cursor moving 1 place ahead If you look at the sequence from 1->3 ='s the grey = that stays on is the one from inside the cursor

For the dom I guess it's happening since the joined characters are in the same span and the cursor is covering it full. Might be hard to fix as it'd need to be a separate element then. And might cause issues with emoji's or cjk as they are multi character too.

[jerch]

For the dom I guess it's happening since the joined characters are in the same span and the cursor is covering it full. Might be hard to fix as it'd need to be a separate element then. And might cause issues with emoji's or cjk as they are multi character too.

Yep, compound unicode chars (grapheme clusters) basically have the same issue, imho this was the reason for inventing IMEs in the first place - the user needs a way to interact with its "construction phase" (cursor access to its atomic entities).

AFAIK word processors treat clusters this way - once they are constructed the normal cursor would not allow to jump into the atomics anymore (treated as a single char, cursor jumps right over it, BS would delete it as a whole), but have the ability to re-enter the construction phase by some additional action to modify the atomics again.

While we can learn from word processors, how a proper cursor based interaction with clusters may look like, it is not quite easy to apply for a grid-aligned terminal. We basically would need a way to re-enter the IME construction once again, no clue if thats possible somehow.

Ligatures as used from coding fonts are somewhat special here as they output different glyphs for consecutive chars, that still show normal monospaced cursor progression. Imho here we should break the ligature, maybe simply skip the joiner if the cursor is above?

[LabhanshAgrawal]

Looks like the rendering issues go further See https://github.com/vercel/hyper/issues/5757

[npezza93]

fwiw @Tyriar @LabhanshAgrawal if you manually clear the texture atlas this goes away. perhaps theres some key that's missing in cache key?

[jerch]

@npezza93 Does this still happen with v5.3? Because in older versions there was a bug in the cache altas, which got fixed around 5.3 (see #4534).

[npezza93]

@jerch yep!