The performance of the DOM renderer is very painful. In several local attempts I tried to isolate the reasons behind this and well, it mainly boils down to the sheer amount of [span elements x CSS rules], which gives the browser engine a hard time to update & layout things.

I was able to find a solution to reduce the "element pressure" by merging cells, that share the same fg/bg settings and where the char content gets properly layouted by the browsers font renderer. This gives a very nice perf boost (test is ls -lR /usr):

• master
  
• WIP branch
  
• compared to webgl renderer
  

Observations from above:

• no more red flagged frames in devtools - most frames can be updated in reasonable time and we see almost no discarded screen refreshs anymore
• the "stattering" got much better - while the DOM renderer still saturates the CPU (the pie chart is still at ~100% usage), the rendering task is like ~7 times faster lifting some of the burden
• JS runtime got much worse, prolly due to the additional merging logic (well, its just a quickly hacked WIP atm)
• overall runtime is on par with webgl renderer with ~14s (prolly hitting an OS/PTY limit here)
• ofc webgl is still far ahead finishing the test rather quick while the CPU idles for ~40% (scales much better in bigger integrations)

So while this looks rather promising, there are ofc downsides - most prominent the fact, that a cell does not strictly refer to a single span element anymore. This currently creates glitches during selection, and most likely will break with any other 3rd party code relying on the a nice cell-span matrix (already an issue for double width chars). Furthermore the merging relies on a "close-enough" threshold approximation, thus will create tiny pixel offsets for bigger merges within a line.