[x] I have searched the issues of this repo and believe that this is not a duplicate
OS version and name: Windows 10 Anniversary Edition
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
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.
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.
I just noticed that clearing the console window using CTRL+L helps.
Maybe related to https://github.com/electron/electron/issues/11051
Same here, it's totally unusable now.
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 ๐ ).
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.
@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.
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.
I will also note I just tested the macOS version and it seems to not be effected.
+1 on this one.
after upgrading to 2.0.0 (barebone, no plugins) the console became so slow its unusable.
Can confirm, it's unusable on Windows 10 anniversary.
Seems to get exponentially slower as the number of displayed lines grows...
Quick look into dev tools show 'drawImage' to be slow.
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.
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.
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
@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.
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..
@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.
@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.
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.
I actually have the same issues with macOS High Sierra.
This is probably https://github.com/electron/electron/issues/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 https://github.com/zeit/hyper/issues/2833#issuecomment-381689454, https://github.com/zeit/hyper/issues/2839
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 https://github.com/electron/electron/issues/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
--ignore-gpu-blacklist
totally fixes it for me even though my windows machine only had Intel HD Graphics.
Argument --ignore-gpu-blacklist
also fix it for me.
I can confirm that, too (on macOS).
open -a Hyper --args --ignore-gpu-blacklist
and everything is smooth.
Confirmed. Works for me on macOS.
open /Applications/Hyper.app --args --ignore-gpu-blacklist
I can confirm that --args --ignore-gpu-blacklist in Windows 10 made it run fast!
How would you pass that argument into the AppImage linux version?
@Tyriar Thank you so much for your insights. I'll study how to always running --ignore-gpu-blacklist
and the potential downsides.
Can also confirm --args --ignore-gpu-blacklist worked for me on Windows 10
I built a macOS (dmg) canary version with ignore-gpu-blacklist
flag set by default: https://file-uwnqivoumn.now.sh
@bpeab @simonhaenisch @travisbotello Can you confirm me that this version fixes your issue? (Do not replace your installed version, this one is not signed and auto-update couldn't work)
@chabou Thanks! Your version also fixes the lag.
@chabou I can also confirm that I was having this same issue on macOS High Sierra, and that your Canary version of 2.0.0 fixes the lag. Thanks. ๐
@chabou Same here. It works great. โ๐ผ
Landed in our v2.1.0-canary.1 release ๐
I'm still getting 300-400ms animation frames on Windows 7, running v2.1.0-canary.1. Any suggestions? Hyper is still completely unusable for me in its current state and I can't stand any other terminal on Windows :sob:
Just installed v2.1.0-canary.1 and it seems to have fixed the issue. You guys rock!
Same for me here. Thanks โ๐ผ
Is there a way to disable pushed updates? It keeps auto-installing v2.0.0 and I have to reinstall v2.1.0-canary.1 over again ๐
@olivier-w why don't you change the updateChannel
to 'canary'
?
@simonhaenisch Thank you! I totally missed that ๐
Issue still going on even with canary on Windows 10 (WSL).
Going back to 1.4.8 solves the issue.
the --ignore-gpu-blacklist seemed to solve the problem
@heynemann I recommend you to open a new issue with steps to reproduce, then we can take a closer look at your issue, this issue has been resolved in latest canary with --ignore-gpu-blacklist
, your must be something else ๐
I'm still having an issue with high input lag and high CPU as I type on Windows 7...just to double check, is this the correct command?
/C/Users/username/AppData/Local/hyper/app-2.0.0/Hyper.exe --args --ignore-gpu-blacklist
@jaxspades you need to use the canary version, that is not possible in 2.0.0 stable, read about using canary here: https://zeit.co/blog/canary#hyper
Thanks! I switched to canary and I'm still having an issue with lag. It seems to take a couple hundred milliseconds for each keystroke, and a few seconds for ls
on a moderate sized folder. Do I need to do something else with my setup, other than using cmd
to open "canary" version hyper
with --args --ignore-gpu-blacklist
?
@jaxspades you don't have to add args anymore with our 2.1.0-canary.1
. Please verify your version with about box. Thank you for your feedback ๐
I can confirm that this is still happening with 2.1.0-canary.1 on Windows 10 (most up to date) with a vanilla install and empty .hyper.js
file, though I did update my nvidia drivers a few days ago. Even tried the --args --ignore-gpu-blacklist
trick. No luck. I've reluctantly reverted to using the Ubuntu WSL prompt window for now. It's ugly. Will probably just downgrade to some earlier version of Hyper if a system restart doesn't fix it (I restart ~monthly, so it'll be a while).
EDIT: it just up and stopped working one day (slowed down). Probably Windows's fault. After a restart and a reinstall, it's working again. Hoping whatever it is doesn't happen again...
Same here. It stopped for a bit and now started again and very very laggy. I switched back to 1.4.8 as a result
Same with me, switching back to older version in the mean time...
@BrysonR @AustinTruex68 have you tried the canary build which skips the GPU blacklist and gives back the performance (GPU accelerated canvas, blacklist is for webGL bugs, we do not use webGL)
I was on 2.1.0 Canary when I started experiencing again and downgraded.
@chabou, @albinekb I'm using 2.1.0-canary.1
now, and still experiencing input lag on Windows 7. Also a vanilla install and config (aside from changing it to canary update channel).
I just upgraded to 2.1.0-canary.1 and although I noticed a slight improvement, the input lag is still happening. I am using Windows 10
Same here on Windows 10, upgraded to 2.1.0-canary.1 and had slight improvement, but still pretty bad input lag. Currently using 1.4.7 and it's doing fine.
My Mac is using the latest and is having no issues though.
Same issue windows 10. I even had Version 2.0.0 stable and upgraded after I noticed the issues. Neither version worked properly. --args --ignore-gpu-blacklist
also did nothing for me.
It's like a gradual slowdown as more and more text appears on the screen.
Same here, tried 2.0.0 and 2.1.0-canary and opening some file in emacs and holding up or down is super painful:
2.1.0-canary.1
made it usable again for me.
@alexqhj try the canary, it's using GPU rendering for the canvas ๐
I probably didn't make it clear enough. I had the issue on both 2.0.0 stable and canary. What's weird is that 2.0 worked fine for months until one day it just didn't. Probably a windows update.
As of now, hyper is useless for me. I might jump down to 1.x and see if that works.
1.4.8 #OlFaithful
1.4.8 also resolved the issue for me.
Same here. 2.0 stable. Just typing in vim. Perf screenshot attached.
For me, the canary build solved it as well... Debian based Linux
$ 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
@sebinsua, how to run this on Linux.
/opt/Hyper/hyper --ignore-gpu-blacklist
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.
Does hyper v2 leverage electron v2?
Having this issue with the latest version using WSL + Zsh. Fine initially and a gradual slowdown until it's unusable.
Not yet @BrysonR
:sad-face:
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.
Yeah, was having the same issue here on macOS High Sierra. Solved by updating to 2.1.0 canary release.
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?
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
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.
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.
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.
Canary 2.1 works well on Ubuntu 17.10
Chiming in that moving from 2.0 stable on latest Win 10 to the latest Canary fixed all input lag for me .
Canary 2.1 on Mac Mojave is still laggy here.
I, too, am experiencing lots of lag when typing in 2.0.0 for Windows 10.
Can confirm heavy input lag in v2.0 on windows enterprise. Using pre-release canary 2.1 worked wonders.
Canary 2.1.0-canary.2 (stable) working perfectly on Windows 10
https://github.com/zeit/hyper/releases
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.
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.
~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
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.
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.
Please make a new issue if this still happens with recent canary CI builds
Most helpful comment
This is probably https://github.com/electron/electron/issues/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 probablyHyper.exe
, on Linux/opt/Hyper/hyper
.See https://github.com/zeit/hyper/issues/2833#issuecomment-381689454, https://github.com/zeit/hyper/issues/2839