Skip to content
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

Rendering issues with webgl and ligatures #3303

Open
LabhanshAgrawal opened this issue Apr 8, 2021 · 10 comments
Open

Rendering issues with webgl and ligatures #3303

LabhanshAgrawal opened this issue Apr 8, 2021 · 10 comments

Comments

@LabhanshAgrawal
Copy link
Contributor

Details

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

Steps to reproduce

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

Canvas
Screenshot 2021-04-08 at 20 17 55
Webgl
Screenshot 2021-04-08 at 20 19 35

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
Screenshot 2021-04-08 at 20 18 09

On typing ==
Canvas
Screenshot 2021-04-08 at 20 19 09
Webgl
Screenshot 2021-04-08 at 20 20 21

On typing ===
Canvas
Screenshot 2021-04-08 at 20 19 18
Webgl
Screenshot 2021-04-08 at 20 20 28

Looks like remnants of earlier paint are there in webgl

@Tyriar
Copy link
Member

Tyriar commented Apr 8, 2021

The grey = is tracked in #3288, not sure what's happening with the :, what font is this?

@LabhanshAgrawal
Copy link
Contributor Author

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

@LabhanshAgrawal
Copy link
Contributor Author

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

@Tyriar
Copy link
Member

Tyriar commented Apr 8, 2021

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
Copy link
Contributor Author

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
Copy link
Member

jerch commented Apr 9, 2021

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
Copy link
Contributor Author

Looks like the rendering issues go further
See vercel/hyper#5757

@npezza93
Copy link
Contributor

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

@jerch
Copy link
Member

jerch commented Nov 22, 2023

@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
Copy link
Contributor

@jerch yep!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants