xtermjs / xterm.js

A terminal for the web
https://xtermjs.org/
MIT License
17.66k stars 1.63k forks source link

Vivid curly #4880

Open tisilent opened 12 months ago

tisilent commented 12 months ago

fix #4064

tisilent commented 12 months ago

before: before

after: after

To be resolved.... When fontSize 40, before: 40b

When fontSize 40, after: 40a

Using more variants can solve this problem, I'm wondering if there's any other way.........

tisilent commented 11 months ago

@Tyriar hi.

fontSize 25

style 1: zoom1

style 2: zoom2

Style 2 can be further beautified. But when the cell width is singular, there is still no way to solve it.

Tyriar commented 11 months ago

@tisilent these two have the ideal shape:

image image

They just need some anti-aliasing

tisilent commented 11 months ago

They just need some anti-aliasing

anti-aliasing 😯

next: cellWidth 19 cell19 !!!

jerch commented 11 months ago

@tisilent Is that still a tiling algo approach? Your last image kinda implies that. I am not sure, if a tiling algo will ever satisfy glitch-free drawing for a curly line at different font sizes - you'd basically need to find several tiling pattern for different zoom levels / font-sizes in the end.

(I may repeat myself here...) I suggest to give up the cell tiling approach for the curve drawing. Instead it might be much easier to find several good looking curves at different font-sizes, then draw those to the full viewport width into a cache, and during rendering clip draw parts of them under cells with curly underlines. Should to the trick. This idea gives up a certain curve shape at the start/end of a cell, which should give you more freedom to draw a nice curly line w'o stitching/aliasing artifacts. The important trick is to take the part of the whole cached line directly under the cells in question, which always gives you a perfect continuation of the curly progression.

Our eye/perception is more aware of tiny shape breaks on repeating pattern, than it would get bothered by curly shapes not perfectly in line with cell/glyph borders.

tisilent commented 11 months ago

@jerch This is an attempt made with the existing structure unchanged, It seems that it cannot be perfectly solved...

you'd basically need to find several tiling pattern for different zoom levels / font-sizes in the end. Yes, it's quite troublesome. It's not a good practice.

(I may repeat myself here...) I suggest to give up the cell tiling approach for the curve drawing. Instead it might be much easier to find several good looking curves at different font-sizes, then draw those to the full viewport width into a cache, and during rendering clip draw parts of them under cells with curly underlines. Should to the trick. It should be possible to combine it and achieve better performance. ☺️

tisilent commented 11 months ago

https://github.com/xtermjs/xterm.js/blob/fb2c39cb5748e071e0a1ed49824590aafd45e65e/src/browser/renderer/shared/CellColorResolver.ts#L146-L148

An extra 3 bits will solve the problem...

jerch commented 11 months ago

It should be possible to combine it and achieve better performance. ☺️

Yes, there are perf implications from my idea above - it would need a quite different row drawing setup like an additional row composition step, e.g. first mask under/overline parts into the empty row, then clip glyphs onto that. This is most likely slower than doing all at cell level at once (the tiling approach suits the kernel idea in opengl much better). Whether thats unbearable slower I cannot tell though. It might be possible to stick to the cell tiling approach also for the over/underlines, if you find a function fully describing such a full viewport width (curly) line by also depending on the cell position in the row, e.g. curly(fontSize, CellXPos) --> ... and allow some "overdrawing" to the right and left to level out stitching breaks.

Tyriar commented 11 months ago

I find the variant tile idea is quite elegant as everything is done initially when drawing the texture and assigned a new identifier, no additional draw steps are needed. This is why the current curly pattern repeats every cell.

To make this nicer with variants we could just keep the pattern repeating every cell (ie. variant 0) and then only when needed to make the underline more natural looking can we add additional variant(s). So based on the width of the cell determine the maximum number of variants to be used which will define the shape of the curl. This is just improving the current situation by giving us more possible shapes to play with.

tisilent commented 11 months ago

@jerch Variant starts from here #4349

tisilent commented 11 months ago

first

:yum:

Code not processed I'll take care of it these days. It also expands the memory footprint and requires optimization. Testing, etc.....

tisilent commented 11 months ago

@Tyriar Using underlineOfferset,I want to migrate from ext related to underline,But there were some significant changes. Also changed the Map to 5 keys.Look at those that need to be adjusted.

tisilent commented 11 months ago

fontSize 36 36-1 36-2