improve decoration rendering efficiency

[Tyriar]

Testing #145629

Could repro this slowness by filling the buffer and then searching for a single letter, this is on a 12th gen i7 (fast modern CPU):

A similar thing happens when pressing enter in this state since we don't do any diffing, just clear and re-render.

Ideas to explore:

• Move from rendering each decoration to calculating colored zones which merge similar rectangles into the same zone and render them
• If the buffer is full, explore shifting the texture up depending on how much scrolling occurs (might be tricky to get right)

[Tyriar]

xterm.js issue: xtermjs/xterm.js#3703

[Tyriar]

After update no more overlap problems:

[connor4312]

I'm not sure how to verify this, it seems like decorations don't show consistently, e.g. notice that only the first "vscode" is highlighted here:

When I try to run node -e "console.log('hello\n'.repeat(10 * 2000))" to fill up the buffer and look for "hello", nothing gets highlighted at all. And while I can click the up and down arrows to navigate between matches, the UI looks disabled as if there were no matches (but doesn't have the "no matches" text)

Reopening since I think something might have broken here.

[meganrogge]

@connor4312 that is by design - we don't show the count or decorations beyond 1000 results

[meganrogge]

you'll need to set workbench color customizations to see the results highlighted.

here are some examples:

        "terminal.findMatchBorder": "#ce1a1a",
        "terminal.findMatchHighlightBorder": "#00ffbf",
        "terminalOverviewRuler.findMatchForeground": "#00c8ff",

[connor4312]

Got it. With 900 results I'm still seeing a pretty decent delay on my macbook, which looks similar to the original problematic one Daniel posted