
Integrated Terminal Performance Improvements - Tyriar
https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer
======
w0utert
I really wish Microsoft had used a different platform to build VS code on,
like C#/Mono, Java, anything except Javascript/Electron basically. I just
started using VS code for C++ development, trying to switch from Vim, an I
basically like everything about the concept, but the execution and
quality/polish of the software is mediocre at best. At least three times a day
random stuff breaks: code completion stops working, switching between
header/source (using a plugin) stops working, all keyboard input except
shortcuts stops working, Vim plugin acting up, the app randomly starts to use
40% cpu until I kill it etc. On top of that performance is just so-so for most
things (editing, autocomplete), and quite slow for others (e.g. gotoSymbol for
the whole project). This was very disappointing for me to find out considering
all the praise VS code gets for being ‘probably the best Electron app’.

I don’t mean this as a flame, but the software just feels like all the other
applications I tried that are based on web technology. If it works everything
is fine, but if you stress the application enough, inevitably things start to
fail in ways that suggest it was simply too difficult to properly QA and test
the thing to the point it doesn’t hit some weird platform edge case. I
sincerely think the product itself is awesome, apparently that’s enough for
people to put up with the shoddy stability and general sense of quality?

Maybe there are other reasons and the platform is not actually the problem,
but I find it remarkable that something as advanced as VS code fails in
similar ways my own web-based projects usually fail.

And now I read they are going to implement their own console rendering using
HTML canvas, because the obvious ways to implement it when you are stuck with
a Electron have major shortcomings... Somehow I just feel Microsoft with all
their talent and resources could have made an even more impressive product if
they had made the exact same thing based on some other platform...

~~~
CJefferson
Something is seriously wrong with your setup. I know many vscode users, and
none of them are having your problems.

I'm not saying you aren't having real problems, but they aren't common and
they can appear in any editor -- I used to fill vim with plugins and it would
hang frequently.

~~~
w0utert
My setup is just the official, latest release, with the Microsoft plugin for
C++, the Vim bindings everyone uses, and one additional plugin for switching
between header and source. I customized nothing besides a few keybindings and
enabling neovim mode. This is on Ubuntu by the way.

I also used VS code a little on macOS for web development, and to be fair, I
didn’t run into any of these problems there. But that’s for projects that are
literally 100 times smaller than the C++ project I’m working on.

I don’t really buy the anecdotal ‘other developers never have any problems
with VS code’ observation. I’ve been following the VS code release
announcements here on HN for a while (it’s what got me interested in trying VS
code), and they regularly seem to contain fixes for weird platform problems or
regressions, to the point they’ve even had to retract a few of them because of
serious problems found after deploying the update.

~~~
nwienert
Look at the past threads for releases (I wont link, but) they are filled with
nothing but praise. I'm totally non-affiliated with VSCode, but switched from
Atom a few months ago and yes, anecdotally it's been an amazingly smooth
experience.

I am actually the opposite of you: totally thankful for JS and electron, and I
think they are the best possible future for apps.

To be honest, I really think people have an emotional reaction to JS/Electron
one because it's seen as a threat to their preferred language, and two because
it has all this built up hate due to legitimate past problems. A few years of
pretty hectic pace in JS-land and now it's close to greatness, but still very
inconsistent, so people still love to hate it. Couple that with some poorly
made apps (looking at you Spotify/Slack) and you have a weird sect on HN that
now vilifies Electron/JS with totally incorrect arguments about stability and
speed (both are very doable with modern practices).

I'm not saying you are this person, or your grievances aren't real. But I'd be
happy to put some money on the following points:

1\. Electron/JS apps will be more prolific in the next 5 years

2\. They will also be clearly the best platform for speed, stability and
flexibility due to massive and ever improving ecosystems and dev tools.

Both have been happening, and to be honest, today we're at a point where I
think it's a no-brainer to choose JS for just about any complex UI. The
problem is you're wading into a fast-changing, diverse ecosystem, and a few
wrong choices there can be very painful.

~~~
santaclaus
> it's a no-brainer to choose JS for just about any complex UI

Javascript? Sure. Electron? Maybe not. Show me an Electron app with load times
that aren't measured in seconds. Or an Electron-based text editor that doesn't
choke on a moderately sized text file. VS Code is currently taking half a gig
of ram on my notebook with three text files open...

I happen to quite like VS Code, but to claim that Electron is a no-brainer is
simply false. There are serious tradeoffs.

~~~
chowyuncat
VS Code doesn't seem to choke to moderately sized files. There is a large
amount of non-Electron code used for its text editor.

------
nwrk
Excited that terminal is getting love. Thanks team VSCode.

Hope the configurable panels allowing terminal on right side will get merged
soon.

[0]
[https://github.com/Microsoft/vscode/pull/34267](https://github.com/Microsoft/vscode/pull/34267)
[1]
[https://github.com/Microsoft/vscode/issues/2806](https://github.com/Microsoft/vscode/issues/2806)

------
revelation
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
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
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
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.

------
Waterluvian
What's the case for using the terminal in VSCode? I use a modern multitasking
computer where VSCode is in one area or screen and my terminal in another (and
other things in others).

By using my own terminal I get to keep everything custom about that terminal
rather than having another one.

Surely there's reasons that I'm missing?

Edit: thanks for all the responses. A lot of great new things I didn't think
of before!

~~~
nwrk
For example, you can use linter in terminal which makes click on output
messages interactive -> going directly to source code.

edit: quick youtube example how it works together
[https://www.youtube.com/watch?v=cMrDePs86Uo](https://www.youtube.com/watch?v=cMrDePs86Uo)

~~~
lobster_johnson
Wouldn't it be better to run the linter in the background and have the editor
mark the problem lines? I have keyboard shortcuts bound to "next marker" and
"previous marker" so I can jump to the next problem.

They don't work across an entire workspace, sadly, and I have an outstanding
Github issue about it that has not seen any activity for years. Project-wide
linting is something that VSCode really lacks right now. For example, it's
easy to change something in one file that breaks another file, but you won't
get any error markers until you go to the broken file.

~~~
jamesgeck0
> Wouldn't it be better to run the linter in the background and have the
> editor mark the problem lines? I have keyboard shortcuts bound to "next
> marker" and "previous marker" so I can jump to the next problem.

The ESLint plugin does both these things; linting is just an example. I use
the terminal's click-to-open file feature for opening files that have have
merge conflicts during git rebase, and for opening spec files that failed.
It's just handy to have.

------
dy
Love the integrated terminal in VS Code! Great work by the team on this and
appreciate the writeup.

Curious what keyboard shortcut people use to move focus from editors to the
Terminal and create new terminals? Anyone use tmux inside terminal?

~~~
Tyriar
Author of the blog post here. The standard shortcuts are ctrl+` for toggling
the panel and ctrl+shift+` for creating a new terminal. This is what I use on
top of that:

{ "key": "ctrl+`", "command": "workbench.action.terminal.focus", "when":
"!terminalFocus" }

This will focus the terminal if the focus is anywhere else, if the terminal is
focused it will close it.

You can add this one if you want ctrl+` to only toggle focus between the
terminal and the last editor:

{ "key": "ctrl+`", "command": "workbench.action.focusActiveEditorGroup",
"when": "terminalFocus" }

On tmux, Joao from the team did a write up on configuring persistent sessions
in the terminal using tmux [https://medium.com/@joaomoreno/persistent-
terminal-sessions-...](https://medium.com/@joaomoreno/persistent-terminal-
sessions-in-vs-code-8fc469ed6b41)

~~~
lobster_johnson
Last I checked, this only makes sense on US keyboards. On most non-US
keyboards, the backtick requires option/alt and isn't practical as a shortcut.

~~~
anontrot
I think you could just add a custom keybinding now that you know the commands.

------
koolba
> Misaligned characters: Due to many monospace fonts not being strictly
> monospace for some Unicode characters, this could lead to situations like
> the one seen on the right-side of the image below: (image)

What are they referring to? I've been staring at the pic for nearly a minute
and can't see anything misaligned.

~~~
batmansmk
Top right and bottom right corners of the green box.

~~~
koolba
Oh duh! I was staring at the text that I didn't even notice the borders.
Thanks!

------
FBISurveillance
Obligatory comment: I really like VSCode but keep jumping back and forth
between it and Sublime because of startup time.

I like VSCode enough to use it daily and extensively and jump back to sublime
when I need to jump around projects fast–when startup time becomes crucial.

I believe they will solve this issue at some point.

~~~
lobster_johnson
While VSCode is great, it's also useless as $EDITOR.

It's very slow to start (when it's already running), and while you'd think you
could speed this up by making it open a new tab in your current window _and_
and return control the parent process when you close that tab ("code -r -w", I
believe), that's not possible. It can open the new tab, but it never
relinquishes control, at least not for me.

Wouldn't be an issue if startup was super fast with "code -w", but creating
new windows, even when VSCode is running, takes several seconds.

So I still use "joe" as $EDITOR.

~~~
Tyriar
> and while you'd think you could speed this up by making it open a new tab in
> your current window and and return control the parent process when you close
> that tab ("code -r -w", I believe), that's not possible.

Exactly this is actually coming in v1.17.

~~~
lobster_johnson
Awesome. Of course, fast window startup would be even better.

------
the_common_man
[https://github.com/sourcelair/xterm.js/pull/938](https://github.com/sourcelair/xterm.js/pull/938)
is the PR does rendering using canvas

------
anontrot
I've been using VSCode for a while. I have this one issue with it, I couldn't
figure out how to switch between the Terminal & the editor. Often I just (CMD+
Tab) to go to an independent terminal and execute some command. The only way I
could figure out to do this within VSCode is "Contrl + ~", but have to do it
twice if it's already open. So, does any of you know if there's an easy way of
switching between the editor and the terminal?

~~~
suswombat
If i understand you correctly this should help you, especially the answer by
Tyriar.
[https://github.com/Microsoft/vscode/issues/12054](https://github.com/Microsoft/vscode/issues/12054)

~~~
anontrot
Oh boy you just saved my ass, thank you!

------
helloimraghav
I'm an iOS Developer learning React, using Webstorm I can get all the auto
completion + some other things I like from Xcode. Can I set up VS Code to do
the same?

~~~
styfle
I don't have experience with React Native, but certainly React + TypeScript
gives you autocomplete in VsCode.

Try cloning my repo here:

[https://github.com/styfle/react-server-example-
tsx](https://github.com/styfle/react-server-example-tsx)

------
theyregreat
Are there any macOS terminals like iTerm but with performance and resource
efficiency as the top goals?

~~~
unrealhoang
You can try Alacritty

~~~
jamesgeck0
Alacritty is extremely fast, but you need to use a terminal multiplexer like
tmux or screen if you want commonly used features like tabs or scrolling.
Which would be fine, except that both tmux and vim run significantly slower
than expected in Alacritty on macOS; there's a performance bug somewhere.

------
polskibus
That's great! Does anyone know if the code editor itself uses canvas
rendering? If not then why?

~~~
altano
It doesn’t use canvas

~~~
copperx
Having never looked at the source, I'm curious about how you build an editor
using web technologies. Is it just a big textarea that gets manipulated with
JS?

~~~
simlevesque
It's not one large textarea. There is a textarea which is 1x1 and right next
to the cursor. I have no idea what they are for.

Just open the dev tools and have some fun. You'll learn a lot.

~~~
lobster_johnson
The textarea is to accept input, presumably. It's a trick often used in a
normal browser HTML page, too. You get focus, keypresses, copy/paste, etc. via
the native browser UI. It's a shame that HTML doesn't provide something
similar, but as a hack it's not too bad.

------
jordache
Why are they focusing on this when there is a huge usability problem on osx +
high res displays

~~~
KayL
I'm using a macbook pro and it seems fine. Is the text blurry on 4k/5k?

~~~
FBISurveillance
I own LG Ultrafine 5K; when I work with VS Code full screen it blinks like
framerate is 10fps or something. Otherwise it works OK on MacBook screen.

~~~
reljac
I'm running a Touch Bar MBP connected to the LG UltraFine 5K with no visible
problems FullScreen or not on the LG panel.

Resolution is set for "Default for display" and I run Flux. Initially I had
some issues with the monitor that went away when I got a new USB-C cable.
Perhaps that would help...?

