4 ms·

That is pretty concerning if they have to drop down to what is essentially a slightly improved framebuffer to get acceptable performance for a terminal emulator

That is pretty concerning if they have to drop down to what is essentially a slightly improved framebuffer to get acceptable performance for a terminal emulator. The Electron waters are shallow and when you jump in head first you might hit a performance wall sooner than your feet hit the water. I predict that by 2020 they'll have migrated the editor and terminal emulator to an OpenGL surface.

WorldMaker 9y ago
Or maybe you just underestimate the demands of a terminal emulator? More specifically, the demands of many users of a terminal emulator. People want to try to see the matrix, they want 60fps scrolls full of arcane details too quick to actually be useful, but clear enough to kind of skim to give the impression that it may be useful. VSCode isn't the first terminal emulator to use a videogame canvas renderer approach (by decades), and won't be the last. (Not just because the work was PRed to a shared library that other applications use too, but also because there will always be people trying to see the matrix in terminal emulators as long as there are terminals to emulate.)
- revelation 9y ago
  That was done because it was the only method available or because they started out with high performance / low latency / ... goals. Here is the VS Code team saying DOM performance was useless. And at the end of the day we're talking about 80x20 characters, sometimes color.
  - WorldMaker 9y ago
    No, the VS Code team is saying DOM performance isn't enough for the high performance / low latency demands they are seeing. The performance with DOM was already good enough for all my needs, personally. They had a lot of people wanting 60fps consoles, so they decided to take a 60fps approach, and even though it is "just" text/color/limited graphics, it shouldn't be a surprise that the 60fps approach is the same one they would take for a more graphics-focused approach somewhere else.
Zaskoda 9y ago
I don't think it's entirely fair to say that they had to drop down. I suppose that all comes down to what you mean by "acceptable". Personally, I think they chose terminal rendering as something to optimize and I think it's a great choice. You emphasized "terminal emulator" in your comment. I don't think they chose to optimize the terminal because it was new ground, but rather because it's a well understood problem space. The Electron waters are limited, yes. But I think it's nice to see developers pushing at those boundaries, no?

WorldMaker 9y ago

Or maybe you just underestimate the demands of a terminal emulator? More specifically, the demands of many users of a terminal emulator. People want to try to see the matrix, they want 60fps scrolls full of arcane details too quick to actually be useful, but clear enough to kind of skim to give the impression that it may be useful. VSCode isn't the first terminal emulator to use a videogame canvas renderer approach (by decades), and won't be the last. (Not just because the work was PRed to a shared library that other applications use too, but also because there will always be people trying to see the matrix in terminal emulators as long as there are terminals to emulate.)

revelation 9y ago
That was done because it was the only method available or because they started out with high performance / low latency / ... goals. Here is the VS Code team saying DOM performance was useless. And at the end of the day we're talking about 80x20 characters, sometimes color.
- WorldMaker 9y ago
  No, the VS Code team is saying DOM performance isn't enough for the high performance / low latency demands they are seeing. The performance with DOM was already good enough for all my needs, personally. They had a lot of people wanting 60fps consoles, so they decided to take a 60fps approach, and even though it is "just" text/color/limited graphics, it shouldn't be a surprise that the 60fps approach is the same one they would take for a more graphics-focused approach somewhere else.

Zaskoda 9y ago

I don't think it's entirely fair to say that they had to drop down. I suppose that all comes down to what you mean by "acceptable". Personally, I think they chose terminal rendering as something to optimize and I think it's a great choice. You emphasized "terminal emulator" in your comment. I don't think they chose to optimize the terminal because it was new ground, but rather because it's a well understood problem space. The Electron waters are limited, yes. But I think it's nice to see developers pushing at those boundaries, no?