jerch

Some background on this - the error is actually a safety measure by xterm.js to avoid OOM. This would happen, if xterm.js gets more than 50MB in the write buffer...

@skipmeister123 Currently xterm.js (the emulator lib behind FluentTerminal) can only operate with JS strings (UTF16 internally) or UTF8 encoded bytes, thus we are bound to UTF world atm. We have...

The problem with SIXEL and windows is ConPty. The way they shaped it internally cuts most wsl applications from higher features of the POSIX terminal interface. (Background: ConPty basically acts...

This is imho an almost similar problem to the curly underline - we get stitching artefacts due to single cell rendering. If we want to keep the single cell rendering...

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 -...

> 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...

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...

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

@Tyriar This a really good idea, it would lower CPU stress for multiple shrinking events in a row. The halving also sounds good to me, it would also lift some...

Did a quick test with a 100k scrollback terminal filled (only testing col shrinking): old ~320ms vs. new ~160ms for resize runtime - speed doubled. :smiley_cat: Seems nodejs does not...