I'd guess thats a visual artefact, like from antialiasing? (it even seems as if the zero crossings are brighter than the slopes...)

No good idea how to fix that - maybe give the curly line more weight, or a tiny bit more luminance? Only guessing here, I have no clue of visual perception tricks...

I was thinking to review this at a bunch of device pixel ratios on Windows and Mac and tweak it to make it more consistent looking, probably just bumping the line width up and maybe the curve too. There is some rounding logic going on with the other lines also to make them solid pixel lines without AA if possible, this could be adding to them looking a little different.

probably just bumping the line width up and maybe the curve too.

Maybe making the curve steeper in the zero crossing will already do? At least thats the main difference I see to my old attempt here: https://user-images.githubusercontent.com/6193135/76248036-d50c3f00-6240-11ea-855b-37e8aec72014.png

Oh well that also was 3 px high, looking at your example above it might still work with 1px more for the curve height.

That should make the line more solid as it's straight, but it's not exactly curvy. Will see how it looks after some tweaks vs the zig-zag/squiggly approach.

Here's monaco's:

I think it uses a repeating underline image, the underline in the webgl renderer is included in the glyph's texture so it currently must be repeatable by the width of a cell:

Here's Chromium's:

This was the one that looks terrible because it appears to be cached with the glyph and doesn't repeat

Dotted 🤢

Ah monaco's curvy line seems to use the same progression in px as I did. Would it be possible to make a "wave painting function" from that without restarting it for every cell (thus dependent from screen position progression) to avoid cell stitching artefacts? (If thats possible at all, cause it might need to draw the wavy thing separately in a whole and subtract glyph overlappings afterwards.)

Chromium clearly wins the stitching prize here...

Would it be possible to make a "wave painting function" from that without restarting it for every cell (thus dependent from screen position progression) to avoid cell stitching artefacts?

Two ways this could happen:

1. Separate the underline rendering completely, resulting in essentially another glyph renderer. This would be too complicated/overkill just to make curvy overlines look good.
2. When curvy underline is used, create a separate glyph for every x cell coordinate. This would look great, but add more complexity to how glyph caching works (passing through the x), and cost more memory which probably isn't a big deal.

My gut feeling is these are both overthinking it and we should just do what Chromium does but do it right; similar to what we have now but more polished.

I agree, both seem overkill for what is to be gained here.

I want to give it a try.

@tisilent sure, I expect this one to be a bit difficult though as we need to make it look good at so many zoom levels/font sizes

Would this look better. 🤪

Right side is def. better than left imho - but, can you turn every second curve upside-down, so it becomes more like a sine wave than this spikey pattern?

@jerch hi. Can you feel some curvature?

@tisilent definitely look better, that's a lot like the zig zag-style curly style of VS Code's problems. Does it look ok if you stretch the wave to be 1-2 pixels wider to smooth the curve a little more?

I notice something going wrong towards the end:

@Tyriar Stretching 1-2px will increase the variants, I'll give it a try.