Startup and canvas render window resize that updates devicePixelRatio is expensive

[Tyriar]

After #938

Repro:

1. Launch xterm.js

---

1. Open demo
2. Start performance timeline
3. Press cmd/ctrl and + 3 times

The reason this happens is because it redraws the char atlas, that's also the reason the time gets greater the more cmd/ctrl + is pressed (more pixels). This could be done using OffscreenCanvas and web workers for browsers that support?

[Tyriar]

The best solution to these two issues is to pull the CharAtlas generation into a web worker. This is blocked on OffscreenCanvas support so that we can draw on a worker thread.

The great thing about this solution is that the terminal can start drawing immediately just fine, the CharAtlas is just an optimization that can come in whenever and it will be picked up and used from that point on,.

[parisk]

Sounds good to me.

Just one question. From what I understand, the CharAtlas needs to be generated every time the zoom factor changes.

If this is true, is the web worker going to be an one-off process or something like a daemon waiting to be requested to generate a new CharAtlas? I think an one-off process would introduce less memory overhead overall.

[Tyriar]

One off process is what I'm thinking as it's generally a pretty infrequent thing. If they take a little while to spin up then we could add some time after it's stopped before terminating? (eg. ctrl++ multiple times)

[parisk]

Great catch. 👍

[Tyriar]

There's an example of generating the char atlas using a web worker at https://github.com/Tyriar/xterm.js/tree/955_worker. I'll probably leave it there for now and wait for Electron to get a version out that supports OffscreenCanvas.