Input Very Laggy After Update to 2.0

[BrysonR]

• I am on the latest Hyper.app version

• I have searched the issues of this repo and believe that this is not a duplicate

• OS version and name: Windows 10 Anniversary Edition

• Hyper.app version: 2.0

• Link of a Gist with the contents of your .hyper.js: https://gist.github.com/BrysonR/d37a699fced1f16ea451e3015344fdd0

• Relevant information from devtools (CMD+ALT+I on macOS, CTRL+SHIFT+I elsewhere):
  total init time 515.8100000000002 bundle.js:1 [Violation] 'requestAnimationFrame' handler took 371ms bundle.js:1 [Violation] 'requestAnimationFrame' handler took 357ms bundle.js:1 [Violation] 'requestAnimationFrame' handler took 354ms bundle.js:1 [Violation] 'requestAnimationFrame' handler took 399ms bundle.js:1 [Violation] 'requestAnimationFrame' handler took 394ms bundle.js:1 [Violation] 'requestAnimationFrame' handler took 404ms bundle.js:1 [Violation] 'requestAnimationFrame' handler took 373ms

• The issue is reproducible in vanilla Hyper.app: Is Vanilla

Issue

Since upgrading to 2.0 a few minutes ago any prompt input is incredibly laggy. Looking at the dev tools console it looks like requestAnimationFrame handler is taking between 300-513ms to respond from a few test keystrokes I did for the purpose of this issue.

[jeyj0]

I can confirm this issue. I have a bare-bones installation, no plugins enabled. I am using it for Linux Subsystem on Windows. I noticed it getting more and more extreme with each "git status -s", but basically any command will do.

[jeyj0]

I just noticed that clearing the console window using CTRL+L helps.

[chabou]

Maybe related to electron/electron#11051

[bjaskj]

Same here, it's totally unusable now.

[MartinMuzatko]

This is very embarrassing, considering the effort you put into 2.0
After downgrading to https://github.com/zeit/hyper/releases/tag/1.4.8 everything is fine again (or at least back to the normal level of slowness 😉 ).

[BrysonR]

Only issue is that it constantly tries to update and there's no auto-update toggle off so if I accidentally restart Hyper or my computer I have to go through the process of uninstall => reinstall => pin to taskbar => properties => advanced => check run as administrator. Needless to say, it's tedious.

[BrysonR]

@chabou curious why you closed this then referenced an issue from 2016. As pointed out in my issue description, per the console, I'm having 300-500ms of latency per keystroke which is unusable and in no way even close to any other terminal. Switching back to v1.4.8 returns it back to normal, more performant than other terminals, speed. So this is definitely an issue with 2.0

EDIT: My mistake. Misinterpreted the closed tag that git auto generated from the other already closed issue.

[BrysonR]

Also, in reference to your electron reference, that's linux specific. As pointed out again in my description, I'm on Windows 10 anniversary edition.

[BrysonR]

I will also note I just tested the macOS version and it seems to not be effected.

[ranglust]

+1 on this one.
after upgrading to 2.0.0 (barebone, no plugins) the console became so slow its unusable.

[danmindru]

Can confirm, it's unusable on Windows 10 anniversary.

• no plugins enabled
• no console errors

Seems to get exponentially slower as the number of displayed lines grows...
Quick look into dev tools show 'drawImage' to be slow.

[jeyj0]

Seems to have to do something with displaying fonts. If I have time later I'll investigate further, but I noticed that changing fonts can improve performance.

[simonhaenisch]

I have the same input lag issue when using the Source Code Pro font (on a Macbook Pro 2011)... can confirm that the input lag goes away when I use the default fontFamily setting.

I also noticed that rendering output is really slow (regardless of the used font, and I have no plugins installed). I screen-recorded running ls -alh in my home folder in a newly created window. It took 0.95s for the first output to render and 1.8s till the prompt was available again. Quite unusable.

[albinekb]

If you change the font and restart the app, is there still input lag? Xterm has an advanced character map to speed up rendering, maybe it's not getting re-initialized correctly after changing font @simonhaenisch

[simonhaenisch]

@albinekb I tried restarting with a custom font, in the first prompt it seemed fine... but after printing something to the output (like listing a directory), the lag came back. Then I tried disabling the custom font and restarted and realized that the lag is actually the same.

So it doesn't seem to be related to the font really, but only to how many characters have been printed already. The more characters, the slower it gets. But what bugs me even more is how long it takes to render the output of a simple command like listing a directory.

Edit: Clearing the buffer (Cmd+K) after printing something removes the lag again.

[albinekb]

Can you try with completely vanilla .hyper.js (just move your old one and restart hyper so you get the vanilla one), and then just change the font? Also try changing your shell to rule out any weirdness.

It sounds like something is making the character map to not be applied, it could be that you have some transparency differences in your config or something, hard to debug so try to rule out everything.

Sorry for the inconvenience, but I can't reproduce..

[gruffled]

@albinekb I've just done this and it made no difference at all. Even the first dir command takes an age to display the results.

Edit: Even the window itself seems to pause before exiting now as well. Not sure if that's related.

[simonhaenisch]

@albinekb I used app cleaner to delete any hyper related config and cache files, and deleted ~/.hyper.js and ~/.hyper_plugins, then re-installed. Didn't help.

I narrowed it down though, it's related to the amount of characters being visible. After I list my directory, the input lag is there, but if I just hit enter a few times to move it out of view, then the lag is gone again (same effect as clear or Cmd+K). The more characters there are visible, the more lag there is.

Edit: I checked activity monitor and saw that high-performance gpu is not being used, which means that there would probably not be any gpu acceleration (?). I read something about the gpu-blacklist for chromium/electron in #2833 and the Early-2011 MBP GPU (AMD Radeon HD 6750M) might be on that list... maybe that's related.

[AustinTruex68]

Having the same issue, huge latency, very hard to use. - Windows 10, no plugins, just plain ol hyper.
Tested on my Mac, and it had no issues.

[bpeab]

I actually have the same issues with macOS High Sierra.

[Tyriar]

This is probably electron/electron#11051, try running hyper --ignore-gpu-blacklist. Note that you will need to run this against the actual hyper executable, not the CLI script. For Windows this is probably Hyper.exe, on Linux /opt/Hyper/hyper.

See #2833 (comment), #2839

[Tyriar]

Hyper may actually have the liberty of just always running --ignore-gpu-blacklist unless --disable-gpu is specified? I haven't explored doing this for VS Code as the terminal is an optional component; the editor runs without canvas.

You may also want to explore updating to Electron 2 asap which will improve the situation (not fully resolve electron/electron#12042). It's currently in beta but I expect it to be stable in the coming weeks: https://github.com/electron/electron/releases/tag/v2.0.0-beta.7

[mtsiedent]

For me, the canary build solved it as well... Debian based Linux

[pielco11]

$ hyper -v

Impossible to open the shared object, file or directory does not exist

Ubuntu 16.04, no issues with 2.1.0-canary.1

[AriPal]

@sebinsua, how to run this on Linux.

/opt/Hyper/hyper --ignore-gpu-blacklist

[jporter-dev]

Still having this issue with 2.1.0-canary2. Issue is most prominent when a webserver logs have printed out a few lines. And it's unusable when using tmux. I can detach from tmux and re-attach using cmder or even the standard bash terminal with zero input lag.

[BrysonR]

Does hyper v2 leverage electron v2?

[matthewlilley]

Having this issue with the latest version using WSL + Zsh. Fine initially and a gradual slowdown until it's unusable.

[albinekb]

Not yet @BrysonR

[BrysonR]

:sad-face:

[nidnogg]

I'm having a different albeit similar situation - running MacOS El Capitan and the input lag is there as soon as I open it. Tried the --ignore-gpublacklist fix posted here earlier to no avail. Reinstalling, and or deleting .hyper.js doesn't fix it.

[ethanent]

Yeah, was having the same issue here on macOS High Sierra. Solved by updating to 2.1.0 canary release.

[nidnogg]

I tried following your suggestion and it finally solved the latency. However, within 5 seconds of seeing my Hyper restored, I get a popup saying version 2.0.0 is stable and it asks me to restart. Even if I do tick the X, it still downgrades and brings the latency back with it.

I fiddled around with the .hyper.js file and this happens even after switching to the 'canary' channel. How do I stop this auto-updating?

[BrysonR]

I believe the shortcut in Start Menu and if you pin it to your taskbar use C:\Users\<UserName>\AppData\Local\hyper\Update.exe as the Target. I switched mine to C:\Users\<UserName>\AppData\Local\hyper\Hyper.exe so it doesn't try and update on start every time.

@nidnogg Hope that helps

[BrysonR]

I just got a new box and installed v2 canary and still noticed some lag when comparing it to cmd. I think lag might be more noticeable given I'm a Mavis Beacon prodigy and type faster than the average user...probably.

[jocho-here]

I'm on Ubuntu 18.04.1 LTS and using Hyper 2.0.0. As soon as I start typing ls multiple times, it lags gradually and becomes very slow within 12 ls command runs. I can confirm that version 2.1.0 canary doesn't have that laggy error. I will go on and try this one out until I see another problem popping up.

[ptolideh]

I'm on Windows 10 and using Bash & ZSH. After adding canary to the .hyper.js speed went up noticeably.

after doing so, I suggest closing and re-opening hyper from the main folder (mine is inside AppData) and wait for it to give a "restart" prompt.

[YoungElPaso]

Canary 2.1 works well on Ubuntu 17.10

[hammypants]

Chiming in that moving from 2.0 stable on latest Win 10 to the latest Canary fixed all input lag for me .

[dbpolito]

Canary 2.1 on Mac Mojave is still laggy here.

[nnnnicholas]

I, too, am experiencing lots of lag when typing in 2.0.0 for Windows 10.

[mvenaas]

Can confirm heavy input lag in v2.0 on windows enterprise. Using pre-release canary 2.1 worked wonders.

[shawnolson-fp]

Canary 2.1.0-canary.2 (stable) working perfectly on Windows 10
https://github.com/zeit/hyper/releases

[Metrakit]

It's really slow too on macOS Mojave. Im using iTerm for a long time and I'm trying to switch to Hyper but it's really slow when I'm typing.

[fgilio]

It's really slow here too, the machine is this one:

What I found out is that it's not that slow when the window is rather small, but it gets laggy when I go full screen.

[JanSimek]

I also upgraded to 2.1.0-canary.2 and also use the parameter --disable-gpu-blacklist but there is no effect. Windows 10

Please disregard my comment on this issue. I figured out it is not hyper's fault, but Windows protection stuff

[srchulo]

I did the Windows protection stuff mentioned above, but I'm still getting this locally and when I SSH. I also see this issue on my Mac.

[gleich]

I am having latency issues as well. I have a feeling that it is hardware due to the fact that it is fine on my iMac but really slow on my MacBook.

[Stanzilla]

Please make a new issue if this still happens with recent canary CI builds