hyper: Performance regression with maximized window on 2.0.0-canary.9

@Tyriar I need an ordered map implementation for the LRU cache, so I’m relying on the ES6 Map implementation, which guarantees insertion order iteration. We’ll either need to pull in a polyfill, or I’ll need to write a minimal ordered map implementation myself. Alternatively, we can try relying on the iteration order of objects in JS, but that’s also a fairly new addition to the spec, though every major browser does implement it.

Regarding the space characters: I use powerline, and that screenshot is from the demo page which doesn’t use the right font, so I’m guessing it’s just a couple of characters that didn’t render quite right.

The diff isn’t ready for review yet, I just wanted to let people know that I’m working on it, so that nobody else starts to work on the same thing.

FYI: Even with the dynamic char atlas patch set, drawing characters with a background is slower than without, since we make a new call to fillRect for each character (even when adjacent characters are the same color), which ends up being expensive (it takes up nearly half the render time for me).

I’m hoping to tackle that problem next, but you might still want to stick with the :hi Normal ctermbg=none hack for now.

EDIT: Oh, and let me know if you encounter any issues with the new atlas!

FYI, I’m working on an implementation of a dynamic character atlas for xterm.js that allows characters with different background colors to be cached, which should fix most people’s performance issues. It generates a character atlas that looks something like:

The current implementation is here, but it’s still pretty buggy, and needs a bit of work and cleanup before I’m comfortable making a PR out of it, but things are coming along!

cc @Tyriar

I removed set termguicolors and the problem seems to be gone. performance is decent in neovim after that change.

FYI, xtermjs/xterm.js#1413 should negate the need for the :hi Normal ctermbg=none hack once it lands (and hyper cuts a release including it), since it makes the background drawing operation an order of magnitude faster.

@albinekb well it’s more about developer convenience than performance, but IE11 support is needed to run xterm.js within Visual Studio 🙂 https://github.com/Microsoft/WhackWhackTerminal

I found that disabling

• colorscheme
• set termguicolors

Gives me the best workaround performance on Neovim.

I’m using https://github.com/yosiat/oceanic-next-vim Color theme.

Testing with a 320colx90rows term : frame render time is 500ms in vim. I can confirm that setting ctermbg=none on Normal preset reduces frame render time to 80ms. Disabling this theme (it uses some other ctermbg) reduces it to 50ms.

Very nice catch @bgw 👍

Here’s my vimrc. It’s not easy for anyone to pick up and use though, because it depends on a large set of plugins installed using git submodules.

It turns out that I was setting the background color with vim (though I was just setting it to the same color as my terminal’s background, and I’m not using 256 colors). Running :hi Normal gives:

Normal         xxx ctermfg=7 ctermbg=0 guifg=#d8d8d8 guibg=#181818

and running :hi Normal ctermbg=none improves performance significantly.

A took a look at how alacritty does this, and it looks like they populate a glyph cache/atlas when drawing characters, so that the cache is filled with character color combinations that are actually in use, whereas xterm.js is just using a static cache. I’d be interested in trying to implement a similar approach (maybe a simple LRU cache) in xterm.js.