14 ms·

I'm the author of Alacritty, and I'm here to answer any questions!

by jwilm 10y ago

h4nkoslo 10y ago
Cool project, but I have literally never thought a terminal was excessively low-performing enough to prevent work from getting done. What applications benefit from a terminal that's even an order of magnitude faster than the alternative?
- pcwalton 10y ago
  Noisy build processes?
  - deleted 10y ago
    [deleted]
- jwilm 10y ago
  Terminal performance is fine at smaller sizes and with less going on. In a multi-pane tmux window with vim, performance issues start to become noticeable. Many people I've talked to have experienced a situation where a bunch of output is being written to the screen, they panic to hit C-c, and then all you can do is wait for it to finish. This just isn't an issue with Alacritty. Alacritty is about having tools that don't get in your way and don't distract you from what you're trying to accomplish.
  - 1_2__3 10y ago
    That's a lot more to do with Vim that your terminal emulator. It chokes on some files pretty reliably.
  - ericbb 10y ago
    With the C-c issue specifically, I don't think that emulator throughput is the most likely culprit. It could be that the emulator is not handling inputs fairly: maybe it tries to process all available input from the pseudoterminal before processing the next batch of keyboard input. Or it could be that the pseudoterminal (kernel driver) is not configured to send the signal as expected. Or it could be that the process you're trying to interrupt is not responsive to the signal. I maintain a terminal emulator that is not optimized at all and I just tested interrupting a process that was dumping one gigabyte of text to the screen. The interrupt was handled instantaneously.
    - JdeBP 10y ago
      It isn't the most likely culprit. The mosh people point out that the place where people hit this is with a SSH session to another machine. Where the data are actually building up is the SSH connection. It's not a problem with the terminal emulators at all.
- simlevesque 10y ago
  > I have literally never thought a terminal was excessively low-performing enough to prevent work from getting done. Which one do you use ?
- deleted 10y ago
  [deleted]
- frozenport 10y ago
  On Windows "std::cout" can take upwards of 3ms. I noticed this when writing high speed camera software that was supposed to hit my callback every 2ms. Instead it was limited by my print statement! Does this emulator solve my problem?
  - mrec 10y ago
    3ms sounds pretty dire, if you weren't writing very much. Out of curiosity, was this with or without `std::ios::sync_with_stdio(false);` ? I've found syncing makes a huge difference to IO perf in Windows, e.g. `_getc_nolock` is much faster than `getc`. (Assuming of course that you can get away with it.)
    - frozenport 10y ago
      That's what I thought, but then I measured. These have little effect, also omitting std::endl has little effect. The effect is somewhat mitigated by buffering, so that if the time between subsequent st::couts is large, you won't see the runtime overhead.
  - netheril96 10y ago
    Windows console is very slow (and terrible in many other ways). I think it is beyond salvageable. The only workarounds is probably write into a disk file or a pipe.
    - Zardoz84 10y ago
      Try to use Cygwin + Mintty . However, keeps being slower that any tty on any *nix. Sometimes fish autocomplete hangs for a few seconds when on the same machine running ubuntu fish autocomplete always is instantaneous. I don't know if it's related to something about the tty emulator or something weird on cygwin.
- snuxoll 10y ago
  Have you even had Control-C take forever to kill that `cat` you accidentally ran against a 1GB log file? I have. Most terminal emulators are 'dumb' and try to render the whole backbuffer sequentially even if what you are seeing is no longer the tail of the output stream. It's not so much that this is 'fast' (because even gnome-terminal which is not what I'd call crazy fast is 'fast enough' most days), but that it's much more responsive as a result. By locking the terminal refresh to your screen refresh rate and only rendering 'current' data this removes a lot of headaches you can run into with other terminal emulators (like the aforementioned cat of a 1GB text file).
  - dom0 10y ago
    I've done that (we all did), but "can't reproduce". So this seems to depend a lot on the emulator, eg. I'm using Konsole, which is superb, and don't see that problem there.
    - GrinningFool 10y ago
      Konsole is the only emulator I've used (other than actual tty) that doesn't have this problem. It's actually been frustrating, becasue there is plenty about it that I don't like. I'll be giving Alacritty a try shortly - if it does what it says on the tin, it's exactly what I've been looking for.
      - eridius 10y ago
        Terminal.app seems to handle this case just fine as well.
        GrinningFool 10y ago
        Thanks, though I've been on linux for the last couple of years. On the mac side I had other performance issues with Terminal.app (particularly when using all of widescreen + tmux - lots of flicker during move/refresh operations). iTerm2 did well for me though, iirc.
        deleted 10y ago
- dom0 10y ago
  I've literally never seen this problem. However, a terminal emulator + X11 and so on can eat a bit of a CPU with noisy processes, eg. the output of mpv eats maybe 5-10 %, because it updates every(?) frame, so maximum work for the whole display stack. Getting the terminal emulator out of sight can get a bit more battery life in these cases. (Somewhat related: If you have infinite scrollback it turns out that /tmp is actually very finite and can be filled by the wrong command with a couple dozen MB/s.)
  - detaro 10y ago
    Sounds like an option to slow down output rendering to e.g. one 1 frame/s might be an interesting feature for a terminal emulator. Still enough to keep an eye on a long-running process, but less overhead?
    - rl3 10y ago
      Smart batching of similar output could be useful as well. Perhaps the ability to configure a similarity threshold.
- loeg 10y ago
  Terminal speed is the primary reason I (and some others) use 'terminology', which is a relatively quick terminal emulator out of the enlightenment project.
- jsz0 10y ago
  It's more of a user comfort / perception thing. Using a slow terminal is basically like playing a game with really inconsistent frame rates. It's a distraction and can cause you to make mistakes from mistimed inputs. In both cases what you're really looking for is consistency more than raw speed.
Manishearth 10y ago
Is split-screen like terminator/iTerm part of the plans? (Yes, I know tmux and screen exist, I just prefer GUI splitscreen)
- jwilm 10y ago
  Nope. The idea is that perf should be good enough that it's not necessary. withoutboats and I are hopefully going to collaborate and add notty protocol support to Alacritty. This should make text splits as performant as GUI splits.
  - Manishearth 10y ago
    My issue with tmux splits is not that it's not fast, it's that GUI stuff like scrolling / selection / etc don't integrate as smoothly.
    - tatterdemalion 10y ago
      I (withoutboats) agree. The real problem in terminals is that this goes both ways - if you let tmux or just vim/emacs split the window, you get no GUI integration - but you use the GUI to split the terminal window, you now have two disconnected shell sections, so none of the CLI integration works. The notty screen splitting protocol should support a "GUI" interface shared by a single process, solving this problem.
ahoka 10y ago
Not really a question, but a request. Given you have a Travis CI setup, could you make binary snapshots available?
- jwilm 10y ago
  This is planned once Alacritty reaches an alpha release. Today's release is considered pre-alpha and is source-only.
- valarauca1 10y ago
  from the readme [1] This initial release should be considered to be pre-alpha software--it will have issues. Once Alacritty reaches an alpha level of readiness, precompiled binaries will be provided for supported operating systems. [1] https://github.com/jwilm/alacritty https://github.com/jwilm/alacritty
- steveklabnik 10y ago
  Incidentally, this is _very easy_ to do with Rust: https://github.com/japaric/trust https://github.com/japaric/trust
vvanders 10y ago
Very cool, how are you handling glyphs? Do you have an LRU font cache or something simpler?
- jwilm 10y ago
  Glyphs are rasterized once and stored in a texture atlas. When rendering a glyph, the fragment shader pulls from that texture. Once loaded, the glyph stays loaded for the duration of the program.
  - vvanders 10y ago
    Got it, just a heads-ups that texture atlas tends to hammer your GPU texture upload if you want to support UTF or non-latin(esp glyph-based) character sets. Not trying to be discouraging just something to keep in mind if that's a direction you want to go. Pretty excited to see a GPU + Rust based stuff making it out into the wild.
    - valarauca1 10y ago
      Question: With a modern discrete GPU card wouldn't the texture atlas just end up in it's VRAM as cards these days commonly have >1GB of VRAM? (Sorry if this is a stupid question, still trying to grok opengl)
      - vvanders 10y ago
        Sure, but you're either going to have to generate the whole font up-front(can be many thousand characters) or you need to re-upload as you use/generate new characters which can thrash unless you're very careful about the regions you lock(and you have a driver that behaves appropriately). Most font renderers I know do a tiered LRU cache of 3-4 texture "pages" which hurts your drawcall batching but tends to be a nice tradeoff in texture usage.
        valarauca1 10y ago
        Okay so I dug into this. There is a font cache on the GPU and another in CPU ram. I believe it will fall into the drawcall batching issue you are concerned about... but terminals don't need to get >60FPS in most cases.
Florin_Andrei 10y ago
> and scrollback are unnecessary Um... that's kind of a deal breaker to me. Really no scrollback at all?
- tetraodonpuffer 10y ago
  the use case seems to be using tmux inside the terminal emulator, with tmux you'd use its own scrollback buffer (edit) from the project's github page in fact The simplicity goal means that it doesn't have many features like tabs or scroll back as in other terminals. Instead, it is expected that users of Alacritty make use of a terminal multiplexer such as tmux.
  - sanderjd 10y ago
    Interesting - maybe this (or someone else) could skip the middle-man and just be a cross-platform tmux gui, instead of a terminal emulator.
    - loeg 10y ago
      Not really. After all, the applications inside tmux are ordinary terminal programs that need terminal emulation.
      - sanderjd 10y ago
        That makes so much sense that I now feel really silly about my suggestion :) Thanks for setting me straight!
  - eridius 10y ago
    The problem with this is using tmux screws with using mouse for selection (since tmux takes over the mouse and does its own selection thing, which usually doesn't do what I want). This approach also means you can't do anything interesting like what Terminal.app does with detecting prompts, marking them, and letting you jump back to them (or clear history back to them). This approach could be excused if the terminal actually natively integrated with tmux, thus providing its own gui splits/tabs that represent tmux's panes/windows, but it doesn't sound like it does that.
snuxoll 10y ago
Any interest in adding tabs and native UI toolkit support?
ekidd 10y ago
I just wanted to say that this looks like a fantastic and very cool project! Congratulations on the speed. Personally, the lack of scrollback and tabs is a dealbreaker for me. I know that I'm supposed to use tmux for that, but I can never remember how tmux scrollback and tab switching work without thinking about them. Plus I rely heavily on mouse selection of multi-screen text in the scrollback buffer. So I'm unlikely to be part of your target audience. (However, I could live without GUI config and menus, because I configure my terminals once every few years at most.) Also, a silly question: Do you support color emoji in the Terminal? I've never quite managed to get it working on Linux.
- jwilm 10y ago
  > Personally, the lack of scrollback and tabs is a dealbreaker for me Completely understandable. This decision was expected to be polarizing. > Do you support color emoji in the Terminal? I've never quite managed to get it working on Linux. Not yet. Fallback fonts, wide chars, and a number of other font rendering items are part of the 1.0 milestone.
  - adelarsq 10y ago
    > Not yet. Fallback fonts, wide chars, and a number of other font rendering items are part of the 1.0 milestone. This will be available also on Windows?
    - jwilm 10y ago
      That's the plan! Most components of Alacritty are platform agnostic aside from font loading, font rasterization and setting up a pty.
  - coldtea 10y ago
    >Completely understandable. This decision was expected to be polarizing. The project being OK with polarizing decisions (instead of listening to the community and discussing it) is the dealbreaker for me. It's OK to build opinionated software, but not at such basic level.
Bedon292 10y ago
Might be a bit early, but will the Windows support be good for Bash on Ubuntu on Windows? Right now I use xming and run xterm inside it, but that is not a perfect solution, especially for things like vim. It works for now, but I am definitely looking for a good alternative.
- nxrabl 10y ago
  Per [0], it looks as though only Bash on Ubuntu on Windows is being targeted, and not CMD or Powershell. [0] https://github.com/jwilm/alacritty/issues/28 https://github.com/jwilm/alacritty/issues/28
Fnoord 10y ago
My current Bash prompt contains a unicode character. I guess this is unsupported? Can report find / works very quick on macOS (so quick, it is unreadable), and Fish works as well. Just the Rust install assumed I was using Bash. Possible bug: on macOS when I minimize Alacritty, and I put it on focus again, it tries to select text. Strangely, not always.
- jwilm 10y ago
  > My current Bash prompt contains a unicode character. I guess this is unsupported? Multibyte characters are 100% supported, but only if they are available in the chosen font. The fallback fonts feature will resolve this issue for you. > Possible bug: on macOS when I minimize Alacritty, and I put it on focus again, it tries to select text. Strangely, not always. Definitely a bug, and it's one that I knowingly shipped with (usually I just resize my terminal once and then it's static). The events triggering selection seem to work slightly different on macOS than Linux. The issue should be easy to resolve, but this comes down to making time.
  - Fnoord 10y ago
    > Multibyte characters are 100% supported, but only if they are available in the chosen font. The fallback fonts feature will resolve this issue for you. How do I enable this feature? The characters  and ⑂ don't work in Menlo.  and  do work in Cousine for Powerline font. In Terminal.App and iTerm2 this works in both fonts. Do those applications also have a fallback fonts feature?
    - dbaupp 10y ago
      It's mentioned in the article as one of the yet-to-be-implemented features.
      - Fnoord 10y ago
        Thank you. Is there a way to command the terminal to enter/exit full screen mode (like iTerm2 has)?
pera 10y ago
Hey, nice project :) I do have a question: you mentioned that urxvt is difficult to configure (because of .Xresources format?), but then you also say that "GUI-based configuration is unnecessary", so how exactly is Alacritty easier than urxvt? One feature that I really miss in rxvt is an easy/fast way to change the color scheme, or at least reverse colors (like with xterm, which if correctly configured it's just ~3 times slower than urxvt). This is something really important when your screen receives direct sunlight.
- jwilm 10y ago
  > because of .Xresources format? Specifically this. Without being above-average proficiency with X, the format and available options are likely to be difficult to figure out. > "GUI-based configuration is unnecessary", so how exactly is Alacritty easier than urxvt The config file is well documented and in a human-friendly format. Most flags will also take effect immediately without restarting the program. > One feature that I really miss in rxvt is an easy/fast way to change the color scheme, or at least reverse colors (like with xterm, which if correctly configured it's just ~3 times slower than urxvt). This is something really important when your screen receives direct sunlight. You could have two `colors` sections in the config file and just uncomment one or the other. Not quite as convenient I suppose. One thing I'm considering as a key-binding option is to exec a command. This could be anything like `sh swap_config.sh` and then you could bind it to whatever you like.
  - saghm 10y ago
    > One thing I'm considering as a key-binding option is to exec a command. This would be pretty awesome. I definitely would love to have that as a feature, assuming it's not excessively difficult to implement.
    - pdkl95 10y ago
      You don't need to implement this in the terminal. You can bind macros to keys in anything that uses readline. Search for "inputrc" and the READLINE section in bash(1). While this is usually used for binding builtin functions (i.e. editing, history), you can simply provide the literal expansion. # in ~/.inputrc $if Bash # <f12> - find this with "<Control-v>{KEY}" "\e[24~": "sh \"${HOME}\"/path/to/swap_config.sh " # (the newline is included, which is # usually bound to accept-line) $endif The string indicating the key to binding to (left of the ":") can change depending on the environment (terminal, os, etc), so use <Control-v> to investigate what is actually being sent by the terminal into readline.
valarauca1 10y ago
Any reason your not using conrod? Browsing the sources it looks like you're re-implementing a non-trivial part of it.
- jwilm 10y ago
  The renderer is custom in order to have complete control over when and how the screen is drawn.
digler999 10y ago
since it's GL-rendered at 60+fps, will I see a much more smooth scrolling effect ? Does scrolling introduce lines discretely or continuously ?
- jwilm 10y ago
  Generally continuously, but it depends on how you scroll. If you're in `less` for example and holding the down key, you will probably see one line at a time, and it should be very smooth. It's possible with high key repeat rates that you might get multiple lines on some frames.
rjayatilleka 10y ago
Very cool project, I'm trying it out, but this is an unrelated question: what is that Vim colorscheme in your screenshot? Do you have a link?
- mifix 10y ago
  According to his dotfile repo[0] it is Tomorrow-Night-Bright. [0]: https://github.com/jwilm/dotfiles/blob/master/vimrc#L6 https://github.com/jwilm/dotfiles/blob/master/vimrc#L6
  - rjayatilleka 10y ago
    Good find, thanks!
Vitaly 10y ago
Why is it starting terminal to run alacritty?
vmarsy 10y ago
This looks like an awesome project! You mention tmux, what about GNU Screen? does it work as well? I don't remember major perf issues using vim within screen, I'm afraid to use Alacritty and then never be able to come back to my past setup :)
- jwilm 10y ago
  From what I understand, screen should be roughly equivalent. I mention tmux because it's my multiplexer of choice.
mistaken 10y ago
cool project, but my question is why? rxvt is plenty fast for general purposes. if your bottleneck is the terminal emulator then you're doing something wrong. can you really read at ~10mbps?
- db48x 10y ago
  No, of course you can't read all of the text at 10Mbps. The problem is that when you start some task which has a lot of spew, just having all of that text scrolling past can slow everything down to the point where the task actually takes longer! Even a few percentage points of slowdown can add up to minutes just sitting there twiddling your thumb. Just a few weeks ago I accidentally ran a command on a remote machine that generated so much spew in the few seconds it ran before I hit control-c that it took 5 minutes to scroll through before I could do anything else. But yes, you probably want to avoid that much text spew even if your terminal is super fast.
  - mistaken 10y ago
    yep: cmd &> /dev/null maybe? :) or ctlr-z; disown; exit... at any rate we're optimizing for edge cases
    - db48x 10y ago
      &>- would be faster, as long as we're at it. But, the point is that sometimes it's a huge cost, and the rest of the time it's a tiny continuous slowdown.
  - JdeBP 10y ago
    You think that your bottleneck is the terminal emulator, but you are wrong. As the mosh people pointed out a few years ago, the output from the remote machine has to scroll for 5 minutes because it is all backed up in the SSH connection between your machine and the remote one. Your bottleneck isn't in the terminal emulator at all, and changing terminal emulators to whizzy new ones will not make any difference to it.
gbuk2013 10y ago
Just another vote for scroll back - would not use without. I do use tmux occasionally but it is just too awkward beyond keeping stuff running in SSH. I also have a tiling window manager and since I use mouse a lot in browser and other GUI apps it's too much of a pain to switch to keyboard only navigation for the terminal.
- jwilm 10y ago
  The tiling WM argument has basically sold me at this point. I'm expecting to open an issue about adding this feature behind a compile-time flag.
jalopy 10y ago
For some reason I can't run Emacs in terminal/unwindowed mode in Alacritty. Every "regular" character I type (ie to enter text into a buffer), Emacs says it's "unrecognized". Control sequences work - ie I can exit with C-x C-e. Works fine in regular Mac OS X terminal. Any suggestions appreciated. Looks like an awesome project!
- jalopy 10y ago
  Nevermind -- Turns out I was just trying to type some characters in Emacs' welcome screen, which doesn't allow that in any terminal. I was so focused on kicking the tires of Alacritty I wasn't paying attention. Looks interseting!
- deleted 10y ago
  [deleted]
stuckagain 10y ago
I put this comment elsewhere in the thread, but maybe if I put it in this subthread you'll get to see it. I tested on my laptop (a ThinkPad X250) and alacritty is slower than xterm. xterm can display find / at 80x24 in 11 seconds, but alacritty takes 17 seconds or more, depending on how large the window is (smaller seems to be slower) and whether it's on-screen or not (off-screen seems to be slower).
- jwilm 10y ago
  There's a small subset of systems experiencing this. Do you happen to have a Radeon video card? In the profile I looked at, glClear was calling down into (through libxcb) __poll_nocancel which was eating 99% of the CPU time. I'm not sure if there's an issue open for this yet, but it's something we're looking into. One of my testers during development ran into this so we're aware of the problem.
  - stuckagain 10y ago
    It seems to be a OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
  - ac29 10y ago
    Another data point with find /: terminator: 0m58s alacritty: 2m46s Up to date Arch Linux. OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.0.3 edit2: there is a bug report tracking this issue here: https://github.com/jwilm/alacritty/issues/125 https://github.com/jwilm/alacritty/issues/125
ndesaulniers 10y ago
I love iTerm2 and hate tmux, but can't use iTerm2 on Linux. I greatly prefer iTerm's window splits and tabs to tmux's. Please reconsider.
- Zardoz84 10y ago
  Use Konsole
rsync 10y ago
"I'm the author of Alacritty, and I'm here to answer any questions!" I don't know whether to throw money at you or tell you to get off my lawn. For now I will wish you a very happy new year and you can have a free rsync.net account if you want. BUT I RESERVE THE RIGHT to shoo you from my lawn once I figure out what is going on here. With your GPU accelerated terminal emulator? Christ.
- valarauca1 10y ago
  >>With your GPU accelerated terminal emulator? Christ. Kids these days with their Rock and Roll music and their 144FPS terminal emulators.
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
greenspot 10y ago
I want to encourage you to keep your product vision. It makes totally sense. I am a heavy tmux + vim user, developing on a remote server. So, I have all my dev sessions always running and can access them on any client. I never needed scrollback or tabs in my terminal. tmux has it all. Excellent window and pane management + scrollback included. And even on a remote connection I feel speed differences between terminal emulators as I wrote in another post. So, there is a strong need for such a product and great that somebody is innovating a console app in a time of locked-down fancy touch devices. Well done and keep on going. Don't be intimidated by different requirements. Your product strategy is right (at least for me).

I'm the author of Alacritty, and I'm here to answer any questions!

by jwilm 10y ago

I'm the author of Alacritty, and I'm here to answer any questions!

Cool project, but I have literally never thought a terminal was excessively low-performing enough to prevent work from getting done. What applications benefit from a terminal that's even an order of magnitude faster than the alternative?

pcwalton 10y ago
Noisy build processes?
- deleted 10y ago
  [deleted]
jwilm 10y ago
Terminal performance is fine at smaller sizes and with less going on. In a multi-pane tmux window with vim, performance issues start to become noticeable. Many people I've talked to have experienced a situation where a bunch of output is being written to the screen, they panic to hit C-c, and then all you can do is wait for it to finish. This just isn't an issue with Alacritty. Alacritty is about having tools that don't get in your way and don't distract you from what you're trying to accomplish.
- 1_2__3 10y ago
  That's a lot more to do with Vim that your terminal emulator. It chokes on some files pretty reliably.
- ericbb 10y ago
  With the C-c issue specifically, I don't think that emulator throughput is the most likely culprit. It could be that the emulator is not handling inputs fairly: maybe it tries to process all available input from the pseudoterminal before processing the next batch of keyboard input. Or it could be that the pseudoterminal (kernel driver) is not configured to send the signal as expected. Or it could be that the process you're trying to interrupt is not responsive to the signal. I maintain a terminal emulator that is not optimized at all and I just tested interrupting a process that was dumping one gigabyte of text to the screen. The interrupt was handled instantaneously.
  - JdeBP 10y ago
    It isn't the most likely culprit. The mosh people point out that the place where people hit this is with a SSH session to another machine. Where the data are actually building up is the SSH connection. It's not a problem with the terminal emulators at all.
simlevesque 10y ago
> I have literally never thought a terminal was excessively low-performing enough to prevent work from getting done. Which one do you use ?
deleted 10y ago
[deleted]
frozenport 10y ago
On Windows "std::cout" can take upwards of 3ms. I noticed this when writing high speed camera software that was supposed to hit my callback every 2ms. Instead it was limited by my print statement! Does this emulator solve my problem?
- mrec 10y ago
  3ms sounds pretty dire, if you weren't writing very much. Out of curiosity, was this with or without `std::ios::sync_with_stdio(false);` ? I've found syncing makes a huge difference to IO perf in Windows, e.g. `_getc_nolock` is much faster than `getc`. (Assuming of course that you can get away with it.)
  - frozenport 10y ago
    That's what I thought, but then I measured. These have little effect, also omitting std::endl has little effect. The effect is somewhat mitigated by buffering, so that if the time between subsequent st::couts is large, you won't see the runtime overhead.
- netheril96 10y ago
  Windows console is very slow (and terrible in many other ways). I think it is beyond salvageable. The only workarounds is probably write into a disk file or a pipe.
  - Zardoz84 10y ago
    Try to use Cygwin + Mintty . However, keeps being slower that any tty on any *nix. Sometimes fish autocomplete hangs for a few seconds when on the same machine running ubuntu fish autocomplete always is instantaneous. I don't know if it's related to something about the tty emulator or something weird on cygwin.
snuxoll 10y ago
Have you even had Control-C take forever to kill that `cat` you accidentally ran against a 1GB log file? I have. Most terminal emulators are 'dumb' and try to render the whole backbuffer sequentially even if what you are seeing is no longer the tail of the output stream. It's not so much that this is 'fast' (because even gnome-terminal which is not what I'd call crazy fast is 'fast enough' most days), but that it's much more responsive as a result. By locking the terminal refresh to your screen refresh rate and only rendering 'current' data this removes a lot of headaches you can run into with other terminal emulators (like the aforementioned cat of a 1GB text file).
- dom0 10y ago
  I've done that (we all did), but "can't reproduce". So this seems to depend a lot on the emulator, eg. I'm using Konsole, which is superb, and don't see that problem there.
  - GrinningFool 10y ago
    Konsole is the only emulator I've used (other than actual tty) that doesn't have this problem. It's actually been frustrating, becasue there is plenty about it that I don't like. I'll be giving Alacritty a try shortly - if it does what it says on the tin, it's exactly what I've been looking for.
    - eridius 10y ago
      Terminal.app seems to handle this case just fine as well.
      - GrinningFool 10y ago
        Thanks, though I've been on linux for the last couple of years. On the mac side I had other performance issues with Terminal.app (particularly when using all of widescreen + tmux - lots of flicker during move/refresh operations). iTerm2 did well for me though, iirc.
      - deleted 10y ago
dom0 10y ago
I've literally never seen this problem. However, a terminal emulator + X11 and so on can eat a bit of a CPU with noisy processes, eg. the output of mpv eats maybe 5-10 %, because it updates every(?) frame, so maximum work for the whole display stack. Getting the terminal emulator out of sight can get a bit more battery life in these cases. (Somewhat related: If you have infinite scrollback it turns out that /tmp is actually very finite and can be filled by the wrong command with a couple dozen MB/s.)
- detaro 10y ago
  Sounds like an option to slow down output rendering to e.g. one 1 frame/s might be an interesting feature for a terminal emulator. Still enough to keep an eye on a long-running process, but less overhead?
  - rl3 10y ago
    Smart batching of similar output could be useful as well. Perhaps the ability to configure a similarity threshold.
loeg 10y ago
Terminal speed is the primary reason I (and some others) use 'terminology', which is a relatively quick terminal emulator out of the enlightenment project.
jsz0 10y ago
It's more of a user comfort / perception thing. Using a slow terminal is basically like playing a game with really inconsistent frame rates. It's a distraction and can cause you to make mistakes from mistimed inputs. In both cases what you're really looking for is consistency more than raw speed.

Manishearth 10y ago

Is split-screen like terminator/iTerm part of the plans? (Yes, I know tmux and screen exist, I just prefer GUI splitscreen)

jwilm 10y ago
Nope. The idea is that perf should be good enough that it's not necessary. withoutboats and I are hopefully going to collaborate and add notty protocol support to Alacritty. This should make text splits as performant as GUI splits.
- Manishearth 10y ago
  My issue with tmux splits is not that it's not fast, it's that GUI stuff like scrolling / selection / etc don't integrate as smoothly.
  - tatterdemalion 10y ago
    I (withoutboats) agree. The real problem in terminals is that this goes both ways - if you let tmux or just vim/emacs split the window, you get no GUI integration - but you use the GUI to split the terminal window, you now have two disconnected shell sections, so none of the CLI integration works. The notty screen splitting protocol should support a "GUI" interface shared by a single process, solving this problem.

ahoka 10y ago

Not really a question, but a request. Given you have a Travis CI setup, could you make binary snapshots available?

jwilm 10y ago
This is planned once Alacritty reaches an alpha release. Today's release is considered pre-alpha and is source-only.
valarauca1 10y ago
from the readme [1] This initial release should be considered to be pre-alpha software--it will have issues. Once Alacritty reaches an alpha level of readiness, precompiled binaries will be provided for supported operating systems. [1] https://github.com/jwilm/alacritty https://github.com/jwilm/alacritty
steveklabnik 10y ago
Incidentally, this is _very easy_ to do with Rust: https://github.com/japaric/trust https://github.com/japaric/trust

vvanders 10y ago

Very cool, how are you handling glyphs? Do you have an LRU font cache or something simpler?

jwilm 10y ago
Glyphs are rasterized once and stored in a texture atlas. When rendering a glyph, the fragment shader pulls from that texture. Once loaded, the glyph stays loaded for the duration of the program.
- vvanders 10y ago
  Got it, just a heads-ups that texture atlas tends to hammer your GPU texture upload if you want to support UTF or non-latin(esp glyph-based) character sets. Not trying to be discouraging just something to keep in mind if that's a direction you want to go. Pretty excited to see a GPU + Rust based stuff making it out into the wild.
  - valarauca1 10y ago
    Question: With a modern discrete GPU card wouldn't the texture atlas just end up in it's VRAM as cards these days commonly have >1GB of VRAM? (Sorry if this is a stupid question, still trying to grok opengl)
    - vvanders 10y ago
      Sure, but you're either going to have to generate the whole font up-front(can be many thousand characters) or you need to re-upload as you use/generate new characters which can thrash unless you're very careful about the regions you lock(and you have a driver that behaves appropriately). Most font renderers I know do a tiered LRU cache of 3-4 texture "pages" which hurts your drawcall batching but tends to be a nice tradeoff in texture usage.
      - valarauca1 10y ago
        Okay so I dug into this. There is a font cache on the GPU and another in CPU ram. I believe it will fall into the drawcall batching issue you are concerned about... but terminals don't need to get >60FPS in most cases.

Florin_Andrei 10y ago

> and scrollback are unnecessary Um... that's kind of a deal breaker to me. Really no scrollback at all?

tetraodonpuffer 10y ago
the use case seems to be using tmux inside the terminal emulator, with tmux you'd use its own scrollback buffer (edit) from the project's github page in fact The simplicity goal means that it doesn't have many features like tabs or scroll back as in other terminals. Instead, it is expected that users of Alacritty make use of a terminal multiplexer such as tmux.
- sanderjd 10y ago
  Interesting - maybe this (or someone else) could skip the middle-man and just be a cross-platform tmux gui, instead of a terminal emulator.
  - loeg 10y ago
    Not really. After all, the applications inside tmux are ordinary terminal programs that need terminal emulation.
    - sanderjd 10y ago
      That makes so much sense that I now feel really silly about my suggestion :) Thanks for setting me straight!
- eridius 10y ago
  The problem with this is using tmux screws with using mouse for selection (since tmux takes over the mouse and does its own selection thing, which usually doesn't do what I want). This approach also means you can't do anything interesting like what Terminal.app does with detecting prompts, marking them, and letting you jump back to them (or clear history back to them). This approach could be excused if the terminal actually natively integrated with tmux, thus providing its own gui splits/tabs that represent tmux's panes/windows, but it doesn't sound like it does that.

snuxoll 10y ago

Any interest in adding tabs and native UI toolkit support?

ekidd 10y ago

I just wanted to say that this looks like a fantastic and very cool project! Congratulations on the speed. Personally, the lack of scrollback and tabs is a dealbreaker for me. I know that I'm supposed to use tmux for that, but I can never remember how tmux scrollback and tab switching work without thinking about them. Plus I rely heavily on mouse selection of multi-screen text in the scrollback buffer. So I'm unlikely to be part of your target audience. (However, I could live without GUI config and menus, because I configure my terminals once every few years at most.) Also, a silly question: Do you support color emoji in the Terminal? I've never quite managed to get it working on Linux.

jwilm 10y ago
> Personally, the lack of scrollback and tabs is a dealbreaker for me Completely understandable. This decision was expected to be polarizing. > Do you support color emoji in the Terminal? I've never quite managed to get it working on Linux. Not yet. Fallback fonts, wide chars, and a number of other font rendering items are part of the 1.0 milestone.
- adelarsq 10y ago
  > Not yet. Fallback fonts, wide chars, and a number of other font rendering items are part of the 1.0 milestone. This will be available also on Windows?
  - jwilm 10y ago
    That's the plan! Most components of Alacritty are platform agnostic aside from font loading, font rasterization and setting up a pty.
- coldtea 10y ago
  >Completely understandable. This decision was expected to be polarizing. The project being OK with polarizing decisions (instead of listening to the community and discussing it) is the dealbreaker for me. It's OK to build opinionated software, but not at such basic level.

Bedon292 10y ago

Might be a bit early, but will the Windows support be good for Bash on Ubuntu on Windows? Right now I use xming and run xterm inside it, but that is not a perfect solution, especially for things like vim. It works for now, but I am definitely looking for a good alternative.

nxrabl 10y ago
Per [0], it looks as though only Bash on Ubuntu on Windows is being targeted, and not CMD or Powershell. [0] https://github.com/jwilm/alacritty/issues/28 https://github.com/jwilm/alacritty/issues/28

Fnoord 10y ago

My current Bash prompt contains a unicode character. I guess this is unsupported? Can report find / works very quick on macOS (so quick, it is unreadable), and Fish works as well. Just the Rust install assumed I was using Bash. Possible bug: on macOS when I minimize Alacritty, and I put it on focus again, it tries to select text. Strangely, not always.

jwilm 10y ago
> My current Bash prompt contains a unicode character. I guess this is unsupported? Multibyte characters are 100% supported, but only if they are available in the chosen font. The fallback fonts feature will resolve this issue for you. > Possible bug: on macOS when I minimize Alacritty, and I put it on focus again, it tries to select text. Strangely, not always. Definitely a bug, and it's one that I knowingly shipped with (usually I just resize my terminal once and then it's static). The events triggering selection seem to work slightly different on macOS than Linux. The issue should be easy to resolve, but this comes down to making time.
- Fnoord 10y ago
  > Multibyte characters are 100% supported, but only if they are available in the chosen font. The fallback fonts feature will resolve this issue for you. How do I enable this feature? The characters  and ⑂ don't work in Menlo.  and  do work in Cousine for Powerline font. In Terminal.App and iTerm2 this works in both fonts. Do those applications also have a fallback fonts feature?
  - dbaupp 10y ago
    It's mentioned in the article as one of the yet-to-be-implemented features.
    - Fnoord 10y ago
      Thank you. Is there a way to command the terminal to enter/exit full screen mode (like iTerm2 has)?

pera 10y ago

Hey, nice project :) I do have a question: you mentioned that urxvt is difficult to configure (because of .Xresources format?), but then you also say that "GUI-based configuration is unnecessary", so how exactly is Alacritty easier than urxvt? One feature that I really miss in rxvt is an easy/fast way to change the color scheme, or at least reverse colors (like with xterm, which if correctly configured it's just ~3 times slower than urxvt). This is something really important when your screen receives direct sunlight.

jwilm 10y ago
> because of .Xresources format? Specifically this. Without being above-average proficiency with X, the format and available options are likely to be difficult to figure out. > "GUI-based configuration is unnecessary", so how exactly is Alacritty easier than urxvt The config file is well documented and in a human-friendly format. Most flags will also take effect immediately without restarting the program. > One feature that I really miss in rxvt is an easy/fast way to change the color scheme, or at least reverse colors (like with xterm, which if correctly configured it's just ~3 times slower than urxvt). This is something really important when your screen receives direct sunlight. You could have two `colors` sections in the config file and just uncomment one or the other. Not quite as convenient I suppose. One thing I'm considering as a key-binding option is to exec a command. This could be anything like `sh swap_config.sh` and then you could bind it to whatever you like.
- saghm 10y ago
  > One thing I'm considering as a key-binding option is to exec a command. This would be pretty awesome. I definitely would love to have that as a feature, assuming it's not excessively difficult to implement.
  - pdkl95 10y ago
    You don't need to implement this in the terminal. You can bind macros to keys in anything that uses readline. Search for "inputrc" and the READLINE section in bash(1). While this is usually used for binding builtin functions (i.e. editing, history), you can simply provide the literal expansion. # in ~/.inputrc $if Bash # <f12> - find this with "<Control-v>{KEY}" "\e[24~": "sh \"${HOME}\"/path/to/swap_config.sh " # (the newline is included, which is # usually bound to accept-line) $endif The string indicating the key to binding to (left of the ":") can change depending on the environment (terminal, os, etc), so use <Control-v> to investigate what is actually being sent by the terminal into readline.

valarauca1 10y ago

Any reason your not using conrod? Browsing the sources it looks like you're re-implementing a non-trivial part of it.

jwilm 10y ago
The renderer is custom in order to have complete control over when and how the screen is drawn.

digler999 10y ago

since it's GL-rendered at 60+fps, will I see a much more smooth scrolling effect ? Does scrolling introduce lines discretely or continuously ?

jwilm 10y ago
Generally continuously, but it depends on how you scroll. If you're in `less` for example and holding the down key, you will probably see one line at a time, and it should be very smooth. It's possible with high key repeat rates that you might get multiple lines on some frames.

rjayatilleka 10y ago

Very cool project, I'm trying it out, but this is an unrelated question: what is that Vim colorscheme in your screenshot? Do you have a link?

mifix 10y ago
According to his dotfile repo[0] it is Tomorrow-Night-Bright. [0]: https://github.com/jwilm/dotfiles/blob/master/vimrc#L6 https://github.com/jwilm/dotfiles/blob/master/vimrc#L6
- rjayatilleka 10y ago
  Good find, thanks!

Vitaly 10y ago

Why is it starting terminal to run alacritty?

vmarsy 10y ago

This looks like an awesome project! You mention tmux, what about GNU Screen? does it work as well? I don't remember major perf issues using vim within screen, I'm afraid to use Alacritty and then never be able to come back to my past setup :)

jwilm 10y ago
From what I understand, screen should be roughly equivalent. I mention tmux because it's my multiplexer of choice.

mistaken 10y ago

cool project, but my question is why? rxvt is plenty fast for general purposes. if your bottleneck is the terminal emulator then you're doing something wrong. can you really read at ~10mbps?

db48x 10y ago
No, of course you can't read all of the text at 10Mbps. The problem is that when you start some task which has a lot of spew, just having all of that text scrolling past can slow everything down to the point where the task actually takes longer! Even a few percentage points of slowdown can add up to minutes just sitting there twiddling your thumb. Just a few weeks ago I accidentally ran a command on a remote machine that generated so much spew in the few seconds it ran before I hit control-c that it took 5 minutes to scroll through before I could do anything else. But yes, you probably want to avoid that much text spew even if your terminal is super fast.
- mistaken 10y ago
  yep: cmd &> /dev/null maybe? :) or ctlr-z; disown; exit... at any rate we're optimizing for edge cases
  - db48x 10y ago
    &>- would be faster, as long as we're at it. But, the point is that sometimes it's a huge cost, and the rest of the time it's a tiny continuous slowdown.
- JdeBP 10y ago
  You think that your bottleneck is the terminal emulator, but you are wrong. As the mosh people pointed out a few years ago, the output from the remote machine has to scroll for 5 minutes because it is all backed up in the SSH connection between your machine and the remote one. Your bottleneck isn't in the terminal emulator at all, and changing terminal emulators to whizzy new ones will not make any difference to it.

gbuk2013 10y ago

Just another vote for scroll back - would not use without. I do use tmux occasionally but it is just too awkward beyond keeping stuff running in SSH. I also have a tiling window manager and since I use mouse a lot in browser and other GUI apps it's too much of a pain to switch to keyboard only navigation for the terminal.

jwilm 10y ago
The tiling WM argument has basically sold me at this point. I'm expecting to open an issue about adding this feature behind a compile-time flag.

jalopy 10y ago

For some reason I can't run Emacs in terminal/unwindowed mode in Alacritty. Every "regular" character I type (ie to enter text into a buffer), Emacs says it's "unrecognized". Control sequences work - ie I can exit with C-x C-e. Works fine in regular Mac OS X terminal. Any suggestions appreciated. Looks like an awesome project!

jalopy 10y ago
Nevermind -- Turns out I was just trying to type some characters in Emacs' welcome screen, which doesn't allow that in any terminal. I was so focused on kicking the tires of Alacritty I wasn't paying attention. Looks interseting!
deleted 10y ago
[deleted]

stuckagain 10y ago

I put this comment elsewhere in the thread, but maybe if I put it in this subthread you'll get to see it. I tested on my laptop (a ThinkPad X250) and alacritty is slower than xterm. xterm can display find / at 80x24 in 11 seconds, but alacritty takes 17 seconds or more, depending on how large the window is (smaller seems to be slower) and whether it's on-screen or not (off-screen seems to be slower).

jwilm 10y ago
There's a small subset of systems experiencing this. Do you happen to have a Radeon video card? In the profile I looked at, glClear was calling down into (through libxcb) __poll_nocancel which was eating 99% of the CPU time. I'm not sure if there's an issue open for this yet, but it's something we're looking into. One of my testers during development ran into this so we're aware of the problem.
- stuckagain 10y ago
  It seems to be a OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2)
- ac29 10y ago
  Another data point with find /: terminator: 0m58s alacritty: 2m46s Up to date Arch Linux. OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.0.3 edit2: there is a bug report tracking this issue here: https://github.com/jwilm/alacritty/issues/125 https://github.com/jwilm/alacritty/issues/125

ndesaulniers 10y ago

I love iTerm2 and hate tmux, but can't use iTerm2 on Linux. I greatly prefer iTerm's window splits and tabs to tmux's. Please reconsider.

Zardoz84 10y ago
Use Konsole

rsync 10y ago

"I'm the author of Alacritty, and I'm here to answer any questions!" I don't know whether to throw money at you or tell you to get off my lawn. For now I will wish you a very happy new year and you can have a free rsync.net account if you want. BUT I RESERVE THE RIGHT to shoo you from my lawn once I figure out what is going on here. With your GPU accelerated terminal emulator? Christ.

valarauca1 10y ago
>>With your GPU accelerated terminal emulator? Christ. Kids these days with their Rock and Roll music and their 144FPS terminal emulators.

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

greenspot 10y ago

I want to encourage you to keep your product vision. It makes totally sense. I am a heavy tmux + vim user, developing on a remote server. So, I have all my dev sessions always running and can access them on any client. I never needed scrollback or tabs in my terminal. tmux has it all. Excellent window and pane management + scrollback included. And even on a remote connection I feel speed differences between terminal emulators as I wrote in another post. So, there is a strong need for such a product and great that somebody is innovating a console app in a time of locked-down fancy touch devices. Well done and keep on going. Don't be intimidated by different requirements. Your product strategy is right (at least for me).