Vivid curly

[tisilent]

fix #4064

[tisilent]

before:

after:

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

When fontSize 40, after:

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

[tisilent]

@Tyriar hi.

fontSize 25

style 1:

style 2:

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

[Tyriar]

@tisilent these two have the ideal shape:

They just need some anti-aliasing

[tisilent]

They just need some anti-aliasing

😯

next: cellWidth 19

!!!

[jerch]

@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]

@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]

xterm.js/src/browser/renderer/shared/CellColorResolver.ts

Lines 146 to 148 in fb2c39c

	// Reset overrides variantOffset
	this.result.ext &= ~ExtFlags.VARIANT_OFFSET;
	this.result.ext |= ($variantOffset << 29) & ExtFlags.VARIANT_OFFSET;

An extra 3 bits will solve the problem...

[jerch]

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]

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]

@jerch Variant starts from here #4349

[tisilent]

😋

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

[tisilent]

@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]

fontSize 36