37 ms·

Show HN: Alacritty, a GPU-accelerated terminal emulator written in Rust

• ninjakeyboard 10y ago
  Cool project for learning and exploration and congrats on making a fast term. I'm not sure that this solves a problem that I have personally.
• jwilm 10y ago
  I'm the author of Alacritty, and I'm here to answer any questions!
  • 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).
• steeve 10y ago
  I love iTerm3, but the speed compared to Terminal.app sometimes makes me jealous. So I guess we all need a faster term emulator :)
  • eridius 10y ago
    Out of curiosity, why do you love iTerm? It's always struck me as kind of ugly (especially its preferences). And AFAIK, the only real feature it has that Terminal.app doesn't (besides the native tmux integration, because I still don't really see the point) is support for apps customizing the 256-color palette on the fly (e.g. the initc capability), and wile I really would like to see Terminal.app gain support for that seeing as how the xterm-256color terminfo it uses declares that it works, lack of support for that isn't a good enough reason to switch away.
    • zie 10y ago
      iTerm has https://github.com/ravenac95/sudolikeaboss https://github.com/ravenac95/sudolikeaboss. Integration of your 1Password passwords with your terminal, which makes life amazing. Typing and copy/pasting passwords(not to mention copy/paste is not exactly secure) is a major time-suck. I'd love generic support for this feature in something like Alacritty.
      • eridius 10y ago
        Interesting, but I don't think I've ever felt the pain of not having that. It's pretty damn easy for me to use the global 1Password hotkey to bring up 1Password Mini, type a few characters to identify the login I want, hit → to expand the login, ↓ to select the password, and ↩ to then copy that password, which I can now paste into the terminal. It's not that hard.
        • zie 10y ago
          with sudolikeaboss, it's hotkey, down arrow(↓) to the one you want, press enter(↩). A lot less keystrokes!
• yeasayer 10y ago
  In terms of speed, Alacritty to Hyper is like Sublime to Atom?
  • brianm 10y ago
    Vim to Atom
    • red2awn 10y ago
      More like butterfly to Atom
      • wsxarcher 10y ago
        More like xi-editor to Atom
        • red2awn 10y ago
          Oh man I really like what Xi editor is doing! Too bad it only have offical support for OSX right now...
• jbverschoor 10y ago
  Very cool.
  • jwilm 10y ago
    Thanks!
• scott_s 10y ago
  This could definitely be tagged as a Show HN (https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html).
  • sctb 10y ago
    Thanks, we've updated the title.
• simlevesque 10y ago
  It really is the fastest one I ever used. Font rendering is great.
• GrinningFool 10y ago
  Thanks for making this and posting it. This is a thing I've been looking for (simple accelerated terminal that performs well) for a very long time.
• llimllib 10y ago
  > Make sure you have the right Rust compiler installed. Alacritty is currently pinned to a certain Rust nightly Ok, I'll... um not do that. Hope you publish a build soon though! edit: more seriously, the nightly compiler situation on rust is going to become a problem as it gets more developer use. I really hope they're able to stabilize it. edit 2: I'm really sorry if I derailed the conversation in a not useful way, @jwilm
  • kbenson 10y ago
    Using nightly for a single build and going back to stable for regular work is not hard. It's a command or two to build and switch, and a command to switch back. Using nightly rust to build a project in development to check it out is like using a beta release of a library to build a project to check it out. In both cases, you expect that it will likely be using stable dependencies in the future, and you can still take a look now.
    • Paul-ish 10y ago
      It seems like the Cargo.toml file for binaries should be able to specify this, and cause the crate to be built with the nightly if it is installed. This way you only have to enter cargo build --release.
      • steveklabnik 10y ago
        Cargo isn't in charge of selecting what rustc you use; that's the job of Rustup. In general, _some_ feature like this is desired; nobody has put in the required work yet.
  • steveklabnik 10y ago
    Looking at the code, it looks like this basically only relies on two things: inclusive ranges, and clippy. But you don't have to use clippy this way; it's just one way of doing it. So it's really one feature. EDIT: Oh oops, and custom derive, which is stable in a month. > I really hope they're able to stabilize it In general, "nightly" is never going to be stabilized. Remember, it's how Rust development works. Some people will always want to be on the cutting edge. I elaborated here: https://news.ycombinator.com/item?id=13277438 https://news.ycombinator.com/item?id=13277438 Also, nightly-only is less of a deal here, since this is mostly an application, not a library. End-users won't need to worry about having Rust at all.
• sigi45 10y ago
  Less repeating that it is fast and more benchmarks instead!
  • stuckagain 10y ago
    Seriously. ^^^ How fast is it? I haven't had a terminal that was as fast as xterm with a matrox millenium ii. That was 20 years ago which is pretty sad. Of course the terminals look better these days.
    • chadcmulligan 10y ago
      yah, 9600 baud is as fast as I need my terminal to go. 19.2K is just crazy.
      • stuckagain 10y ago
        That's not what I said. What I said was that terminal was unbelievably fast. Especially for backwards scrolling which is an important use case to me.
        • chadcmulligan 10y ago
          I was just having a little joke, apologies if it came off as a criticism. It seems very strange to me that people are still talking about speeds of terminals, but not my field (any more) fortunately. One of the first things I wrote was a terminal emulator using telnet to run on PC-DOS using a port of curses to connect to our Sun 3's. To think in 2017 people are still concerned about terminals is very surprising to me.
          • stuckagain 10y ago
            The problem is the terminals have been getting monotonically slower over the last 20 years, whereas the amount of build spew I need to grope around in to find the relevant error has not decreased :-/
• psheets 10y ago
  Does this support crossfire?
• ggame 10y ago
  I'd like to host this terminal in a 3D environment. Any plans to enable this? Perhaps with a signed distance field texture. I'm building a 3D game in Rust and would like to be able to drop this in.
  • elcritch 10y ago
    Oh, just as interesting, plugging this into VR system! Make it way easier to multitask and work on lots of systems (at the risk of looking incredibly goofy).
    • corysama 10y ago
      https://www.reddit.com/r/HMDprogramming/ https://www.reddit.com/r/HMDprogramming/ is all about stuff like that. Not much traffic there, though...
    • ggame 10y ago
      Sadly VR is useless for reading :( I wish it wasn't so. You're much better off with a high resolution screen with the ability to zoom in and out between landmarks. Maybe a head tracker to make navigation more intuitive.
      • eduren 10y ago
        Hopefully that changes with the next bump in pixel density. Aggressive supersampling already is getting close to readable.
        • ggame 10y ago
          I wouldn't hold my breath. Maybe for causal reading but not for day in day out 8 hours a day. It's also solving the wrong problem when it comes to immersion. I fly FPV which is a fuzzy intermittent analog 640x480 screen and it's incredibly immersive. People are fully immersed into their tiny mobile phone screens for a large portion of their day. AR peaked with Pokemon Go and we didn't even need Google Glass, Magic Leap or HoloLens. We already have the hardware for full immersion and it's sitting right in front of you (or in your hand).
• fvargas 10y ago
  > Welcome to nginx! > If you see this page, the nginx web server is successfully installed and working. Further configuration is required. On jwilm.io -- Just wanted to let you know
  • jwilm 10y ago
    Should probably redirect that to the blog; thanks for the notice!
• malensek 10y ago
  Awesome! This is exactly what I've been hoping for. The state of terminal emulators on macOS is particularly bad, at least when it comes to speed. Both the built-in term and iTerm have a lot of features, but really start to lag on big screens with a lot of text. I used to run urvxt under XQuartz for this reason, but there's scaling problems with retina screens these days. Nice work. Hopefully this can fill a particular void for folks that want no-frills fast terminal emulation.
  • SloopJon 10y ago
    I can't remember the last time I thought that my terminal was too slow, except maybe when I tried that Electron-based program a while back (Hyper, I think it was). My priorities are more like the following: 1. Stability. I crashed Alacritty thirty seconds after opening it; possibly related to issue #12. 2. Emulation correctness. In Terminal.app, the cursor often gets out of sync when I "turn the corner" (i.e., backspace across a line boundary). 3. Font rendering. Text in some terminals just looks ugly. 4. Features. Alacritty doesn't seem to show the number of rows and columns when I resize. Scrollback! This looks like a really interesting project, but it seems really strange to make performance such a high priority. I tried the find /usr test, and it seemed equally fast in Terminal.app and Alacritty.
• brandur 10y ago
  I just want to say that this project is amazing. At the risk of sounding hyperbolic, I think Rust is the most exciting thing that's happening in computing today. This sort of project that plausibly replaces software traditionally written only in C/C++ with something that has performance parity, but is in a language where contributions are relatively accessible and safe, is the most exciting thing even within the bounds of an intriguing ecosystem. As someone who is especially concerned about the performance of my tooling these days due to what seems to be a generally infinite willingness to accept web apps that are slower than desktop apps from decades ago, and which seem to continually demand more resources year over year, I really appreciate that such a distinguishing eye has been given to Alacritty's speed and resource usage. Some contemporary alternatives like Electron-based terminals are academically interesting, but are programs I'd never want to use due to the huge step backwards in these areas. One question: do you have any plans to use Alacritty to try and advance the state of terminal emulators more generally? e.g. Displaying images, richer interfaces that don't depend on ASCII bar characters, graphs, properly tabulated results, etc. This is a direction that I wish we were going, but it's not clear to me how to get there without many sacrifices.
  • EnjoyTomato 10y ago
    Why do people still say C/C++? They are two different languages with different purposes and strengths/weaknesses. Rust might be a worthy competitor with C++, assuming many improvements down the line, but it's not even in the same category as C, no matter how much the enthusiasts like to claim otherwise.
  • dragonne 10y ago
    Another Rust terminal emulator project, notty[1], aims to do this. Downthread the author mentions that the projects are looking at collaborating. [1]: https://github.com/withoutboats/notty https://github.com/withoutboats/notty
    • brandur 10y ago
      That's really cool and their README gives some great background. Thanks!
• jackmott 10y ago
  Awww hell yeah.
• richdougherty 10y ago
  > Both the utf8parse and vte crates that were written for Alacritty use table-driven parsers. The cool thing about these is that they have very little branching; utf8parse only has one branch in the entire library! From a simplicity point of view table-driven parsing is pretty neat. However, it does mean you'll be getting a lot of branch misprediction in your single branch, since it's harder for the CPU to predict where it will branch to. You could probably go faster with some handcoding in the parser.
  • ycmbntrthrwaway 10y ago
    Rust has macros so any sort of tables can be rolled out into more efficient code, like if you wrote switch-case in C. It should be possible to rewrite vt_state_table! once later, when it becomes a problem.
• WhatIsDukkha 10y ago
  I really disagree with the authors definition of minimal. Terminal emulators have such a minimal user interface as it is it's a bit boggling that I have to make the case for the following "bloat" that other terminal emulators have. I need scrollback because I do occasionally pick up my mouse and grab things that have scrolled off the screen. Tmux doesn't help with this but maybe there is some magic that I don't know these days. I need tabs. At any given time many of those tabs might have instances of tmux somewhere in their multiply nested depths, generally on remote hosts. I'm not going to start tmux on every local prompt just so I can use Alacritty and thus intentionally starting a tmux in tmux funshow. I use "Monitor for Silence" "Monitor for Activity" pretty consistently. It's free software so I glad the author is making something and hopefully enjoying the process. I can't really use this or consider it until he reconsiders. Maybe he'll get some collaborators that will argue him around on this. Cool project otherwise.
  • elihu 10y ago
    Yeah, that was my reaction. > Features like GUI-based configuration, tabs and scrollback are unnecessary. The latter features are better provided by a terminal multiplexer like tmux. This seems kind of like saying "everyone should use their computer the same way I do". I don't use tmux; maybe I should learn to use it. However, I seem to be getting along fine without it, and no scroll back is a deal-breaker for me. That said, this is still a cool project and I wish them success.
    • jfoutz 10y ago
      > This seems kind of like saying "everyone should use their computer the same way I do". People do have that attitude from time to time, in this case i'd phrase it more like "no one seems to use their computer the way i want to, so i wrote some software"
    • Normal_gaussian 10y ago
      What you said doesn't make any sense to me. Firstly you insinuate that the author is requiring people to interact as they do - this evidently is not the case, a suggestion has even been made on one of many ways to behave differently. Secondly the "I seem to be getting along fine without it" statement pointlessly hampers progress. There is no basis or reasoning for this, instead there is a decision - whimsical by the looks of it - to not use it. You could say that you don't anticipate the gains of the system to be worth the transition cost, or you could actually try it and have some useful criticism, or any number of other things. Thirdly, the linked page doesn't ever mention the 'minimal' your parent introduces. Minimal implies sufficiency (least sufficient, but sufficient none the less), the Alacritty page states simple - which does not. I find the final comment hilarious. You have just denounced a tool based on an implementation triviality (which can be easily bypassed) and choose to summarise with a statement as undoubtedly false as it is trite. Did you read the page?
• anoother 10y ago
  Very interesting use of vsync.. using it to cap redraw time and allow more time for processing...
• dvt 10y ago
  Pretty awesome, but I'm not sure if I want my GPU fans spinning if all I'm doing is looking at a terminal :P
  • jwilm 10y ago
    The amount of time spent doing GPU work is rather small. Battery life tends to be better on my Macbook with Alacritty than with other terminals. This seems to suggest that power consumption is actually less than with CPU based renderers (and that your GPU fans shouldn't be spinning).
    • dvt 10y ago
      I didn't realize there's no Windows version available yet, I was totally thinking about my Windows laptop. My Apple (work) laptop is much better about not turning on fans willy-nilly.
      • dualogy 10y ago
        Not necessarily due to "your Windows laptop", sometimes it's due to hidden/forgotten vendor bloatware and Windows' very own background services. That is, due to shabby software, not your laptop. I disabled Windows Update (rather check it manually every other month) and went through the list of services that'll realistically never be used even indirectly to disable and voila, no more random fan spinning! Until I open a WebGL page or something that is.. that "3D JS" will heat up even a current mobile workstation with a 3GB-VRAM Quadro GPU!
  • outworlder 10y ago
    If you use any modern OS, you are likely staring at textures composed by the GPU. This is no different and, in fact, can eliminate some of the middle-"men".
• shmerl 10y ago
  A pity you can't use Vulkan on MacOS. Otherwise you could have used vulkano[1] instead of OpenGL. 1. https://github.com/tomaka/vulkano https://github.com/tomaka/vulkano
  • jwilm 10y ago
    Even so, I do plan to add a Vulkan renderer at some point using vulkano. My hope is that the build script can choose the best option at compile time.
• callumprentice 10y ago
  https://github.com/unconed/TermKit https://github.com/unconed/TermKit or https://acko.net/blog/on-termkit/ https://acko.net/blog/on-termkit/ TermKit is another terminal app from 2011 designed to modernize the command line experience. Sadly, I don't think it's being worked on anymore.
• epberry 10y ago
  I really like this. It combines my love of tmux and vim with my interest in rust, system software, terminals, and my eternal quest for the fastest, simplest, most cross platform terminal development environment. Great job - looking forward to running nightly builds of this. EDIT: Ah, after a little sleuthing, the recent post from OneSignal on why they chose rust for one of their services makes sense :).
  • rhaps0dy 10y ago
    This reads like it should go in a grad school statement of purpose :)
• epberry 10y ago
  I really like this. It combines my love of tmux and vim with my interest in rust, system software, terminals, and my eternal quest for the fastest, simplest, most cross platform terminal development environment. Great job - looking forward to running nightly builds of this.
• ejp 10y ago
  Wow, I am definitely the target for this. I often have tmux panes watching fast-scrolling log files while trying to continue to work in another pane. I've been trying to tweak tmux to perform better, but it really is the rendering speed that's holding it back. The lack of scrollback/tabs/etc doesn't bother me at all - I use tmux for this exactly as suggested. Thank you for this!
• garaetjjte 10y ago
  Nice, but: thread 'pty reader' panicked at 'index out of bounds: the len is 24 but the index is 24', /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcollections/vec.rs:1371 or thread 'pty reader' panicked at 'cursor fell off grid', src/term/mod.rs:634
• sakabaro 10y ago
  Very impressive. I am manipulating huge amount of text data on a regular basis directly in the terminal, smoother exhaust experiment is a huge win. I wish I can give you some money right now to support the development.
• Asooka 10y ago
  Hm, if we're doing GPU rendering for speed, I'd suggest uploading vector glyph data to the GPU and rasterising on the GPU in the pixel shader, rather than using FreeType. See here: http://wdobbie.com/post/gpu-text-rendering-with-vector-textures/ http://wdobbie.com/post/gpu-text-rendering-with-vector-textu... . The WebGL Demo is really impressive - it lets you zoom in and out on a multi-page PDF at speeds I haven't seen anywhere else.
  • jwilm 10y ago
    Thank you for the suggestion! I've had a few comments suggesting similarly. I plan to investigate this as time permits.
  • dddddannyyyyy 10y ago
    This is not fast. It uses less texture memory but it is not faster than 2 triangles per character. This is why no one really uses this technique in a production system right now.
  • pcwalton 10y ago
    That will lose by a lot overall. Hit rates on the glyph cache are massive.
• sdegutis 10y ago
  How much unsafe code was needed to make this work?
  • steveklabnik 10y ago
    https://github.com/jwilm/alacritty/search?utf8=%E2%9C%93&q=unsafe https://github.com/jwilm/alacritty/search?utf8=%E2%9C%93&q=u... Looks like most for FFI, but there's some other small bits too.
  • jwilm 10y ago
    As Steve mentioned, it was mostly for ffi. There's also a few places where I'm doing my own bounds checking in order to provide nicer error messages. After doing the bounds checking, doing an index operation without the standard library's bounds checking requires unsafe.
    • steveklabnik 10y ago
      Couldn't you use get instead of [] for this? Maybe I'll look into it and send a PR :)
      • jwilm 10y ago
        That seems completely reasonable. Not sure why I didn't consider it. PRs welcome :D
        • steveklabnik 10y ago
          I figured out why: because there are two of them, it's a little awkward... I might have a PR for you, we'll see :)
• 010a 10y ago
  Installation was surprisingly easy. And performance was surprisingly good. `find /Applications` results in... - Unrecoverably crashing Hyper - 1:28 iTerm2 - 0:32 Terminal - 0:20 Alacritty Very impressive stuff. I'll be keeping an eye on this project. And performance was surprisingly good; a `find /Applications` on my computer crashes Hyper, takes 1:28 on iTerm2,
  • GolDDranks 10y ago
    What the heck!? I never knew terminal emulators themselves were such bottlenecks! The more you know... I tried this too. `$ find /Applications` iTerm2 - 0:26 Alacritty - 0:12
• dorianm 10y ago
  Also, Cathode is a terminal made with OpenGl and it's really fast: https://www.jwz.org/blog/2011/01/cathode-vintage-terminal-emulator/ https://www.jwz.org/blog/2011/01/cathode-vintage-terminal-em...
  • rukittenme 10y ago
    That link redirects to imgur for me. edit: or it did but now its going to the website.
    • timlyo 10y ago
      Copy and paste it in. For some reason the owner redirects traffic from hacker news.
    • wincent 10y ago
      Alternatively: `brew cask install cathode`.
• Philipp__ 10y ago
  Oh thank you so much!!! I am right now in dire need of light terminal (read st's equivalent) for macOS, since iTerm2 felt bloated since few years ago and font rendering is kinda meh, and it is slow, and it has many many features I really do not need, and Terminal.app simply doesn't make the cut (no true color support for example). I need speed, true colors, and minimalistic terminal as possible, since I use tmux (tabs and gui not needed) for anything if I need more than one terminal screen. Not sure if this is worth the hassle to set up right now, I might just wait for alpha release. But I am watching this on GitHub and can't wait to try it! (plus it's Rust which almost made me dance in my room)
• gigatexal 10y ago
  This is really cool though I can't seem to get it to build on my mac. Though the stock OSX terminal is plenty fast for me. Maybe I don't do enough intensive work
• deleted 10y ago
  [deleted]
• Arubis 10y ago
  I didn't even realize my (iTerm2) terminal emulator wasn't fast until I tried Alacritty. When doing non-intensive tasks, the difference is less one of vision and more a "feel". And it feels SNAPPY. And, as a heavy tmux user, I'm definitely your target audience. But...the font rendering doesn't look as good as iTerm's, at least not yet. I suspect I'll be swapping once you're at a public build release.
  • MaxLeiter 10y ago
    I'd swap to Alacrity if it supported multiple tabs or buffers like iTerm2
• rafinha 10y ago
  Why does one need 500fps on terminal ? I don't understand the need for the GPU.
  • dbaupp 10y ago
    The article explains the benefits only needing 2ms to render a frame, and how v-sync means it won't actually be displaying at 500fps.
  • mrob 10y ago
    A real 500fps terminal (with 500Hz display) would be nice, because timing jitter would be very low no matter what keyboard autorepeat rate you used. Autorepeat would appear smooth even when the frame rate isn't an integer multiple of the repeat rate. Although in practice something like 120fps is probably sufficient if used with MPV-style motion interpolation.
• sssilver 10y ago
  How do they define performance, and how do they measure it?
  • xorxornop 10y ago
    FPS or more strictly, DUPS (display updates per second), as a function of resource use - that is, what pushes the most text, the fastest, with the most displayed frames (sent to actual display/monitor) corresponding to discrete states of display output (v vis-à-vis the terminal), per second? Some terminals bottleneck standard out ️ display , some hardcode the display rate
• coldtea 10y ago
  >tabs and scrollback are unnecessary. The latter features are better provided by a terminal multiplexer like tmux. I beg to differ. I don't really know whenever there's a project that's almost perfect, there's some braindead decision that cripples it with no good reason. I'd understand it if some more advanced or exotic feature wasn't available, but scrolling?
• vectorpush 10y ago
  For those who rely on tabs, one great advantage of relying on the multiplexer instead is that your "tabs" live within the terminal, so when you ssh into your session, the machine has all your "tabs" ready and waiting instead of tied up in a non-accessible GUI.
• rocky1138 10y ago
  Why OpenGL instead of Vulkan since that's where everything seems to be going these days.
  • jwilm 10y ago
    Vulkan is not yet supported on macOS. There are plans for a Vulkan renderer, but cross-platform support will come first.
• readittwice 10y ago
  so this uses GPU-accelerated rendering with OpenGL. TBH I have never used OpenGL and when I read "GPU-accelerated XYZ" this still sounds like magic to me because I've know idea how this works. Could you point me to some resources where I can read up on this stuff? if this helps you: I am not a newbie, I already know C, C++ and Rust, but I haven't done any graphics programming at all yet. For example I only have a very rough idea what shaders do.
  • buzzybee 10y ago
    I learned this stuff a long while ago, but I found a promising textbook for you to review [0] tldr; the "easy 80%" of the effort in GPU rendering, specifically, is reformatting graphics data in forms that the GPU prefers. (The "hard 20%" is dealing with confusing APIs, broken implementations, etc.) Graphics techniques themselves may apply various mathematics(geometry, trigonometry, a little bit of linear algebra, DSP), either on the CPU or GPU. To render things you make decisions about the processing and output format and write data and algorithms accordingly. [0] http://math.hws.edu/graphicsbook/ http://math.hws.edu/graphicsbook/
• teen 10y ago
  Wex wex exort!
• skybrian 10y ago
  It sounds like a fun project, but I don't really understand what performance issues this solves? I don't think I've ever had an issue with slow terminal rendering using the default terminals on Ubuntu or Mac OS. What sort of applications do you run where it becomes an issue? On the other hand, something like mosh [1] seems like it could be really useful on slow network connections. But that's not about rendering faster. [1] https://mosh.org/ https://mosh.org/
  • zenlikethat 10y ago
    Maybe it's more in reaction to the recent wave of editors and terminals using JavaScript as their primary language ?
  • mrob 10y ago
    Not all people are equally sensitive to graphical performance issues. The default Ubuntu terminal is capped at approximately 40fps[1]. This is deliberate and hard-coded. It's not an integer multiple of any common screen refresh rate and it looks very bad. There is no way to configure keyboard autorepeat so new input is shown with consistent timing. I consider this bad design and I'm happy that Alacritty is limited only by the monitor. But some people might never notice the timing problems in other terminals. [1] https://github.com/GNOME/vte/blob/b517d20379c7a665e897f925ca3ecb7b778364f2/src/vte.cc https://github.com/GNOME/vte/blob/b517d20379c7a665e897f925ca... line 10685
    • jstimpfle 10y ago
      keyboard autorepeat doesn't have anything to do with the terminal emulator (or I would be surprised). There's an X11 setting, try "xset r rate <delay-ms> <repetitions-per-sec>", e.g. "xset r rate 170 30".
      • mrob 10y ago
        The timing of the input itself doesn't vary, but the timing of the visual feedback does. I like a fast 60Hz autorepeat, and I rely on visual feedback for precise positioning (I find this has lower cognitive load than Vim style character/word/line/etc counting). If the terminal is displaying at 40fps then some separate inputs will be merged and displayed at the same time. And if you like 30Hz autorepeat, instead of consistent 2 frames per input, you get a mixture of 1 to 3 frames per input depending on how the cycles line up. It makes it much harder to hit the exact character you want if you're using autorepeat for navigation. Ideally the terminal should have MPV-style motion interpolation for supporting keyboard repeat rates that aren't an integer multiple of the display's refresh rate.
• xedrac 10y ago
  Looks great so far. Other than scrolling support, the one thing I miss the most is the use of the up arrow to scroll through history. Ctrl+R is great, but sometimes I just want to scroll through my most recent commands.
• aoeu345 10y ago
  Just installed on Linux Mint. The installation was quick and painless from the instructions, and it is noticeably faster than my previous MATE terminal. We'll see if I notice a lack of scrollback. Thanks!
• plg 10y ago
  iOS version?
• cyberpunk 10y ago
  Jwilm: This is great, and I'm really looking forward to following this project; beers on me and thanks for the effort! A few findings from my side if you want some feedback, I generally work mosh'd into some beefy servers with a long running tmux I resume -- so I'm probably the use case this is aimed at (client: xps13, archlinux). 1) If I create a vertical split view (tmux_key+v) while I already have some output in the left side of the split, and have nothing but my prompt in the right side; then resizing the split is instant/snappy.. However, if I then do a find / in the 'new' (right) split, ctrl+c it after a moment and then resize it lags/judders hugely -- I'm not sure what's going on there but let me know if you'd like me to try and explain that more if you can't reproduce from that.. This doesn't happen in termite.. 2) I had to set offsets and use a giant font to make it look reasonable on my (highdpi) lappy: font: normal: family: SourceCodePro # should be "Menlo" or something on macOS. style: Regular bold: family: SourceCodePro # should be "Menlo" or something on macOS. italic: family: SourceCodePro # should be "Menlo" or something on macOS. size: 26.0 offset: x: 4.0 y: -30.0 Otherwise: +100 :}
  • jwilm 10y ago
    2. I don't have easy access to the high DPI scale factor, so it needs to be configured manually for now :(. dpi: x: 144.0 y: 144.0 1. That doesn't sound good! Would you mind filing an issue?
    • cyberpunk 10y ago
      Sure I will do when I get a moment :} One other feature that's a killer for me is being able to change the font size while running -- ctrl++/-.
      • jwilm 10y ago
        I've heard that a few times now. For what it's worth, that's in the works!
• elventear 10y ago
  cat /dev/random on macOS Sierra crashes for me.
• jxy 10y ago
  Buzzwords aside, why do we need GPU-accelerated terminal emulators? What is the real speed constraint in a terminal emulator?
• d_kol 10y ago
  Impressive! I run https://github.com/slash-hq/slash https://github.com/slash-hq/slash and it just works.
• Bromskloss 10y ago
  > Using vim inside tmux in many terminals was a particularly bad experience. None of them were ever quite fast enough. When does this slowness show itself?
  • aoeu345 10y ago
    If you have four large files open in Vim tabs, it can be quite slow. If you print out a large text file or script output with cat or less, it can be slow as well. This is on a 1.8ghz i5 machine running Linux. I can already notice the speed of Alacritty. We'll see how it performs in the next few months for me.
    • Bromskloss 10y ago
      < If you have four large files open in Vim tabs, it can be quite slow. Is this at all dependent on the terminal emulator?
• conradk 10y ago
  Not sure why they rebuilt a clipboard library when "clipboard" exists (I think it might even be used within Servo, not sure): https://crates.io/crates/clipboard https://crates.io/crates/clipboard
  • steveklabnik 10y ago
    > A non-GPL licensed cross-platform clipboard library, (That is, that project is GPL licensed, and they didn't want that)
    • conradk 10y ago
      Oh, I thought "clipboard" was dual licensed to GPL and/or Apache 2.0. My bad. I hadn't seen that the x11 related code was purely GPL 2.0. Thanks for your help, Steve !
      • steveklabnik 10y ago
        No worries! :)
• anthk 10y ago
  http://www.bbspot.com/News/2003/02/ati_ascii.html http://www.bbspot.com/News/2003/02/ati_ascii.html Seriously.
• hl5 10y ago
  Great idea and I hope Alacritty continues to evolve because it should eventually be the fastest given the GPU integration. However, st is faster on my system, supports bitmap fonts like SGI screen, handles true color, works when no GPU is present, has half the LoC, and has less dependencies.
  • guilloche 10y ago
    I thought alacrity was faster. If not, I will still use st. But alacrity can still become a GUI terminal later and will have some usage for me.
• dvcrn 10y ago
  As a tmux+vim user, this hits right home for me. I never use terminal tabs and do almost everything inside tmux. The only time during development I use a other app is when I start neovim-qt, just so I have faster rendering and squeeze even more performance out of it. If Alacritty is giving me the same speed without me having to spawn a graphical vim for it, sign me up! I'm going to try this as my main tool for a couple of days and collect some feedback :)
• DavideNL 10y ago
  heh just fyi, my F-secure reports: "Harmful web site blocked. blog.jwilm.io This web site has been reported as harmful. We recommend that you do not visit this web site."
• Gonzih 10y ago
  Love the project! Completely agree with minimalistic philosophy. I can see why some people feel like scrollback would be needed, I personally myself always work in tmux sessions, but still.
• uvesten 10y ago
  Wow. I just installed this on macOS, and the difference in speed compared to iTerm 3 is huge! I always assumed that it was my bloated vim and tmux configs that made it feel a bit sluggish sometimes, but it turns out i was the terminal. Now everything feels instantaneous. After some color bugs have been ironed out I'll switch full-time.
• koyote 10y ago
  Having never thought my current terminal emulator was slow I was surprised to immediately see a difference with Alacritty! That being said, every time I install a package useing apt-get (Xubuntu) Alacritty crashes with the following: thread 'pty reader' panicked at 'index out of bounds: the len is 24 but the index is 18446744073709551615', /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcollections/vec.rs:1371 I guess we're not quite at 1.0 yet but looking good otherwise!
• lngnmn 10y ago
  While GPU accelerated 3D interfaces (like it in 3D games) is a good idea (at least one could mix data visualization and with controls - the way WebGL guys do it) a terminal emulator does not require any acceleration, leave alone having a Nvidia drivers or Cuda as a dependency. What a decent terminal emulator should have is standard compliance and decent font rendering (and freetype is good-enough). Lousy engineering will lead to lousy code, especially when the main objective is to show off (engineering is, obviously, not an objective.) Btw, using Rust is not an engineering.
  • mmstick 10y ago
    Everything that can be GPU-accelerated should be GPU-accelerated. The GPU is far more energy efficient, and every bit of offload onto the GPU leads to a decrease in CPU consumption. Terminals can be particularly CPU-heavy when running a chatty program.
    • lngnmn 10y ago
      I hope systemd guys will read this.
• greenspot 10y ago
  Excited and happy to see such a project! I am using iTerm2 on a maxed-out MBP 15 Retina quad core and Xshell on a $150 Asus Cherry Trail netbook. You won't believe it but Xshell on the crappy netbook feels light-years faster and more responsive than iTerm2 on the MBP. Wondering how Alacritty will perform, looking forward.
• Anilm3 10y ago
  This is a very interesting concept and another example of what can be done with Rust. However and without the intention of discouraging the author, I did not find any performance improvement from Alacritty using Ubuntu 16.04 on an i7-4500U (using integrated graphics HD 4400). Here are some numbers, simply printing the contents of 446 files: At 80x24: gnome-terminal: real 0m0.848s user 0m0.032s sys 0m0.072s Alacritty: real 0m6.832s user 0m0.032s sys 0m0.164s At fullscreen: gnome-terminal: real 0m0.819s user 0m0.020s sys 0m0.088s Alacritty: real 0m8.972s user 0m0.064s sys 0m0.164s The font was a tad smaller by default on Alacritty, changing it made no significant difference in the numbers. Since the difference in performance was quite noticeable I decided not to test other possible configurations, but I could do so if it might help. My graphics card has a pretty poor performance in general so that might be an indication that, since the performance of Alacritty is directly impacted by the graphics card, it might be useful for the author to determine the "minimum requirements" for Alacritty to outperform the competition. In any case, it might not be a fair comparison as the author has stated that this is a pre-alpha release, but maybe he can find it helpful in some way, as he suggests he hasn't been able to find a test in which Alacritty didn't perform as well as another terminal.
  • jwilm 10y ago
    There's a known bug when using Mesa that kills performance. Hopefully we'll get it resolved soon!
• __ddd__ 10y ago
  I really, really like this so far. Interestingly, it's dependence on tmux (which I really like overall) for 'extra' terminal features presents some problems for performance and usability. Tmux has its own non-trivial rendering bottlenecks, the most significant of which comes into play when you have multiple clients attached to a session. As a test, I went into a notes folder and did `grep -r e .`. When Alacritty was sized larger than mate's default terminal, mate's default terminal finished rendering first. When Alacritty was sized smaller than mate's terminal, Alacritty finished first. Also of note was that Alacritty running tmux rendered slower than mate's default terminal without tmux. This was an uncontrolled experiment, especially since this was a tmux session with a couple windows with a couple panes per window, on a tmux server with 2 other sessions (with a lot of vim windows etc), but something tells me the results would be the same if I used a tmux server with one session/window/pane. As a tmux user, this isn't a huge deal to me, but it should be concerning the the Alacritty devs since Alacritty requires a multiplexer to be usable. My biggest concern, however, is not performance related, but usability related. Consider this use case: Alacritty -> ssh into remote server -> run tmux on remote server. How am I supposed to paste anything into that remote tmux session now? Am I supposed to nest my remote tmux session in a local tmux session? That sounds awful! I've found satisfactory workarounds to the lack of copy/paste when working locally, but it falls apart when I can't rely on duplicating the tmux register to the clipboard (and vice versa) because the clipboard is remote. If I can find a workaround to the remote paste issue, I will probably use Alacritty exclusively. Otherwise, I can't use this terminal for remote work, and I'd rather not run two different terminals just so that rendering is faster _sometimes_
  • jwilm 10y ago
    I'm happy to hear you're enjoying it! > concerning the the Alacritty devs since Alacritty requires a multiplexer to be usable The project initially started to be an optimized tmux renderer. It's not supposed to appeal to everybody. That said, there's a big segment of users with tiling window managers that are only blocked by not having scrollback, and we're talking about adding it. Features like tabs/splits will likely never be introduced. > If I can find a workaround to the remote paste issue What platform are you on that the selection copy and mouse paste isn't working? It's also possible to configure this to another keybinding if you prefer.
• 0x445442 10y ago
  Projects like this are so so close but fall just short of the ideal. I've been thinking about this for years but I have not been at the point in my life where I could implement my ideas which are these: 1.) A UI which is just a line/text field to enter commands. Something like the command prompt but which fuzzy matches commands like the mini-buffer in emacs or the omni text field in Chrome or Firefox or even Enso from a few years back. 2.) Each command is name spaced to an "agent" to avoid command collisions. For example agent 'jarvis' would have a set of commands it response to like jarvis/foo, jarvis/bar or jarvis/baz. 3.) The output of each command is a list of 0..N items/objects rendered in a master/detail view where navigation over the list shows a detailed view of each object/item in the list. 4.) An item/object can be anything from an email, rss entry, web page, graphic, tweet, contents from a text file. Basically anything that is renderable. 5.) The output of any command can be piped to any other command which is able to parse the list of items/objects from the prior command and render its own new list. This UI paradigm seems to cover an incredibly large set of use cases. The only use cases I can think of which are not covered are those where the keyboard input device is not sufficient; such things as graphics manipulation where a mouse or pen & tablet are needed. The frustrating thing for me has been to witness the vast number of systems over the years that have nibbled at the edges of this paradigm but have not gone all the way. What I'm talking about mostly here are the numerous launcher systems like Enso or Quick Silver or dMenu. All these systems have UIs very similar to what I'm talking about but they're restricted to launching existing apps and controlling the options exposed in menus of existing apps. The other class of applications I've seen that come close are the ones like that mentioned in this topic. Applications like notty where the effort is spent trying to shoehorn extra rendering capabilities into a terminal emulator. What I want is essentially a Grand Unified User Interface (GUUI) such that applications as we know them are done away with and we only deal with commands and output. A system where I can type web/news.ycombinator.com and a one item list comes back with that first item selected by default in the details view. And that item is the front page of Hacker News. Then I could next type email/inbox and a list of emails in my inbox are rendered. And of course while viewing one of the items in my email/inbox I could type email/reply which would render a text area to reply to my previously selected email. As I said earlier, the use cases seem endless and this paradigm seems like it would be incredibly efficient for those who can type well.
• botverse 10y ago
  Like 58% faster than iTerm2 in my Late 2013 MBP retina. find ~ iTerm2 1m20s alacritty 47s where the find command itself uses between 40% and 50% of a core, the TERM emulator process uses is 5x in iTerm2 iTerm 130% (peak up to 140%) alacritty 25% (peak up to 29%) I'm very excited with this and I'm going to follow the development of alacritty :)
• Aissen 10y ago
  So, like terminology, but with less features ?
• davesque 10y ago
  I added support for Alacritty in my iTerm color scheme conversion tool: https://github.com/davesque/iterm_convert https://github.com/davesque/iterm_convert
• nitemice 10y ago
  A relevant Destroy All Software talk: https://www.destroyallsoftware.com/talks/a-whole-new-world https://www.destroyallsoftware.com/talks/a-whole-new-world