5 ms·

I like to see projects like this pop up because it's so easy to fall into a trap of accepting input latency that other more bloated UI frameworks bring. As we

by nickjj 8y ago

I like to see projects like this pop up because it's so easy to fall into a trap of accepting input latency that other more bloated UI frameworks bring. As we all know, Electron is really bad in this department but it's not limited to Electron. I recently installed native Linux and the problem exists there too. Gnome terminal has a MASSIVE amount of input latency compared to xterm. Even worse than the difference between Electron and any non-Electron app in Windows. I wish more people embraced and went all-in with UI frameworks that were optimized for reduced latency. IMO reduced / low latency input is the most important feature for a terminal or code editor.

t0astbread 8y ago
Agreed. For school I have to use Visual Studio on my laptop and the input lag is just absurd. (Surprisingly Code is pretty good.)
- nickjj 8y ago
  Yeah VSCode is pretty solid in this regard for an Electron app but I hope they continue to try and optimize it. It's still very noticeably delayed compared to something like the default WSL terminal or xterm but VSCode has much lower key press latency than Hyper and a few other Electron terminals like Terminus.
  - vijaybritto 8y ago
    They've re-written many performance sensitive components in C++. Thats why code performs really well. They've done a great job!
    - hueho 8y ago
      I think Atom has components in C++. VSCode is Javascript only.
      - vijaybritto 8y ago
        oh yes sorry! I stand corrected.
    - dragonshed 8y ago
      The code performs really well because, as you say, they've done a great job engineering it. However, they've specifically stated a few cases where C++ wasn't pursued. An example: A while back I read a blog post [1] talking about how they analyzed why the text buffer was causing OOM errors for certain files. It's a really good read, discussing drawbacks of the initial array of lines data structure, and how they came to use the "piece tree" data structure, and some of the tradeoffs therein. [1] https://code.visualstudio.com/blogs/2018/03/23/text-buffer-reimplementation https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
  - tenaciousDaniel 8y ago
    I was astounded when I learned the VSCode was an electron app. I used it for almost 2 years without a clue. Very impressive.
mixmastamyk 8y ago
Interesting, I definitely believe you after reading Dan Luu's posts a year or so ago on keyboard and terminal latency. However I use mate terminal every day and it feels like it responds instantaneously, even over a USB keyboard connected to a dock connected to a laptop. Maybe as long as the latency is below a certain threshold it is no longer noticeable.
- nickjj 8y ago
  It's a tricky thing to perceive because there's a lot of variables at play. A lot of LCD monitors have 50-75ms of input lag. That means you don't even see what you type until 75ms afterwards so you might not even have a chance to see how a low latency application behaves. Then on top of that, there's the human factor. Some people are just more sensitive to this sort of thing. The monitor I use happens to have about 13ms of input lag (verified with camera tests) which is pretty much as good as you can ask for with an IPS panel. I wrote all about picking monitors for programming at https://nickjanetakis.com/blog/how-to-pick-a-good-monitor-for-software-development https://nickjanetakis.com/blog/how-to-pick-a-good-monitor-fo.... The difference is night and day when typing in an application that's not efficient vs one that is. Even typing in this comment box on HN feels like I'm typing in mud because Chrome's input lag is horrendous compared to xterm, WSL Ubuntu terminal or any other application that doesn't have a million layers of UI framework abstractions piled on. If you're curious, one of the developers from the WSL Ubuntu terminal went into great detail on why their terminal is so fast. It's at https://github.com/Microsoft/console/issues/327 https://github.com/Microsoft/console/issues/327. The sad thing is, I've opened high input latency issues to a number of other terminals and the author of those terminals often come back saying "nah, your computer must be broken, otherwise everyone would be complaining" even after I supply them video proof. I guess that's what happens when you live in a world where everyone has low end monitors and are used to using Electron apps all day.
  - mixmastamyk 8y ago
    Yep my gear, especially the dock, probably enforces a minimum latency on everything. The only time latency is noticeable to me is if I can type faster than displayed on screen. I type around 50 wpm so the computer doesn't have to respond that quickly to keep up. Online I found that equals 250 cpm, or ~4.2 cps, lets say it has 240ms per keypress to not fall behind. Plenty of time.
janoc 8y ago
This is for embedded development (e.g. a gui for your washing machine), not a replacement for Electron, Qt, GTK or what have you.
- zorro_young 8y ago
  Yes, GuiLite could embeded in Qt, MFC... And you also could run without them, even without OS.

by nickjj 8y ago

t0astbread 8y ago

Agreed. For school I have to use Visual Studio on my laptop and the input lag is just absurd. (Surprisingly Code is pretty good.)

nickjj 8y ago
Yeah VSCode is pretty solid in this regard for an Electron app but I hope they continue to try and optimize it. It's still very noticeably delayed compared to something like the default WSL terminal or xterm but VSCode has much lower key press latency than Hyper and a few other Electron terminals like Terminus.
- vijaybritto 8y ago
  They've re-written many performance sensitive components in C++. Thats why code performs really well. They've done a great job!
  - hueho 8y ago
    I think Atom has components in C++. VSCode is Javascript only.
    - vijaybritto 8y ago
      oh yes sorry! I stand corrected.
  - dragonshed 8y ago
    The code performs really well because, as you say, they've done a great job engineering it. However, they've specifically stated a few cases where C++ wasn't pursued. An example: A while back I read a blog post [1] talking about how they analyzed why the text buffer was causing OOM errors for certain files. It's a really good read, discussing drawbacks of the initial array of lines data structure, and how they came to use the "piece tree" data structure, and some of the tradeoffs therein. [1] https://code.visualstudio.com/blogs/2018/03/23/text-buffer-reimplementation https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r...
- tenaciousDaniel 8y ago
  I was astounded when I learned the VSCode was an electron app. I used it for almost 2 years without a clue. Very impressive.

mixmastamyk 8y ago

Interesting, I definitely believe you after reading Dan Luu's posts a year or so ago on keyboard and terminal latency. However I use mate terminal every day and it feels like it responds instantaneously, even over a USB keyboard connected to a dock connected to a laptop. Maybe as long as the latency is below a certain threshold it is no longer noticeable.

nickjj 8y ago
It's a tricky thing to perceive because there's a lot of variables at play. A lot of LCD monitors have 50-75ms of input lag. That means you don't even see what you type until 75ms afterwards so you might not even have a chance to see how a low latency application behaves. Then on top of that, there's the human factor. Some people are just more sensitive to this sort of thing. The monitor I use happens to have about 13ms of input lag (verified with camera tests) which is pretty much as good as you can ask for with an IPS panel. I wrote all about picking monitors for programming at https://nickjanetakis.com/blog/how-to-pick-a-good-monitor-for-software-development https://nickjanetakis.com/blog/how-to-pick-a-good-monitor-fo.... The difference is night and day when typing in an application that's not efficient vs one that is. Even typing in this comment box on HN feels like I'm typing in mud because Chrome's input lag is horrendous compared to xterm, WSL Ubuntu terminal or any other application that doesn't have a million layers of UI framework abstractions piled on. If you're curious, one of the developers from the WSL Ubuntu terminal went into great detail on why their terminal is so fast. It's at https://github.com/Microsoft/console/issues/327 https://github.com/Microsoft/console/issues/327. The sad thing is, I've opened high input latency issues to a number of other terminals and the author of those terminals often come back saying "nah, your computer must be broken, otherwise everyone would be complaining" even after I supply them video proof. I guess that's what happens when you live in a world where everyone has low end monitors and are used to using Electron apps all day.
- mixmastamyk 8y ago
  Yep my gear, especially the dock, probably enforces a minimum latency on everything. The only time latency is noticeable to me is if I can type faster than displayed on screen. I type around 50 wpm so the computer doesn't have to respond that quickly to keep up. Online I found that equals 250 cpm, or ~4.2 cps, lets say it has 240ms per keypress to not fall behind. Plenty of time.

janoc 8y ago

This is for embedded development (e.g. a gui for your washing machine), not a replacement for Electron, Qt, GTK or what have you.

zorro_young 8y ago
Yes, GuiLite could embeded in Qt, MFC... And you also could run without them, even without OS.