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.
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.
Um... that's kind of a deal breaker to me. Really no scrollback at all?
As far as I can tell, using Tmux's scrollback instead has no downsides of note, but some _very_ significant upsides. For example, (1) shared buffer between terminal windows, and (2) copy/paste modes that are usable with Vim shortcuts.
(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.
That said, I really wanted to build this exact same project at some point, so maybe seems like a feature that could be added in a fork :)
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.
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.
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.
Kids these days with their Rock and Roll music and their 144FPS terminal emulators.
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).
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.
Does this emulator solve my 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.)
Which one do you use ?
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 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).
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.
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.
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!
Looks interseting!
(Yes, I know tmux and screen exist, I just prefer GUI splitscreen)
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.
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 :)
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.
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.
Browsing the sources it looks like you're re-implementing a non-trivial part of it.
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.
I would strongly argue that this thinking is putting the cart before the horse.
I don't use tmux, nor do I want to (though occasionally I have to use screen as a hack to keep programs running on remote servers, and I hate every second of it). Solutions like tmux arguably exist because terminals have poor UIs, and the terminal protocol is too weak to form the foundation for the kind of interactivity and statefulness provided by modern graphical UIs. If terminals were as powerful as, say, web browsers (not that I'm suggesting that anyone conflate them), the world would be a different, happier place.
I think Hyper [1] is going down the wrong path, but I strongly believe a new "terminal-oriented UI model/protocol" could be invented that would scratch every possible itch — good for text, mouse support, custom UI widgets, seamless remote connections, multiple screen regions — without sacrificing functionality at all.
[1] https://hyper.is
There's been a lot more pushback on the scrolling decision than I had anticipated. It's not something I want in my terminal, but it seems that a simple feature like this is essential for others. Perhaps I should reconsider.
I worry that a "simple" feature like this may be overly complex internally. Performance with large amounts of output is also a concern. At least if we were to add support, it could be designed as a build feature and be removed completely if it were undesired.
I have the opposite impression. I actually anjoy time spent in my tmux + vim setup while I hate the time spent in a web browser. Web browsers seem bloated to me and I always feel like I'm forced to use the mouse too much while using them. I've heard about vimperator, but every time I've tried it seemed poorly integrated (the authors did an incredible job nonetheless).
The only drawback of delegating scrolling to tmux that I see is that my experience running tmux locally and using ssh to use a remote machine with another (remote) tmux session wasn't great. Keyboard shortcuts were usually caught by the local machine and not by the remote one. So I just don't run tmux locally when I want to ssh into a remote machine. Problem solved more or less.
Whilst I totally agree with you, I think Tmux is a lot like vim in its power. Along the same note, I'd wager a gTmux, much like gVim would be q real nice way to multiplex terminals when we get the UI to beat the TUI.
> 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.
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"
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?
I wouldn't trust a third party application to be part of the performance experience I'm claiming for my own application, though.
# Enable mouse support including scrolling
set -g mouse on
# Versions prior to 2.1 may want this too:
set -g mouse-utf8 on
history-limit 5000 # 5000 lines of history per pane. Adjust as needed.Also, scrolling is somewhat unreliable, although I still haven't figured out why.
In any case, I use tmux in some of my terminal tabs, and very frequently I have to hit ⌘R to disable terminal mouse support just so I can select & copy something without tmux interfering (I could also hold down the Fn key, except I use an external Das Keyboard, and the Das Keyboard folks still haven't figured out that their Fn key should actually behave like Apple's Fn key and let the system know when it's pressed by itself, as opposed to what it does now which is simply modifying the keypress events for other keys without sending any independent event for the Fn key).
I can relate to your feelings. In the beginning I was _very_ skeptical about running tmux locally. But very quickly I reconfigured tmux as I felt and stopped noticing at all if I work locally or remotely. Everything is very smooth and pleasant since then.
The only bad thing I remember: default tmux keybindings suck. I just redefined almost everything.
It's true, e.g. ^B / Ctrl+B is a terrible prefix. All of this just makes tmux harder to learn, and less portable/transferrable. But I think there's value in having to feel out the ideal configuration for your workflow - but the prefix is still inexcusable.
The ESC thing is fixable by configuration, at least, but I really doubt I can make tmux behave like my native terminal.
If you spend a lot of time in the terminal, there's a lot of value to be gained from using tmux. It takes some configuration to get value from it, but there is value there.
For what it's worth, I use tmux just like the author of this project: a single urxvt terminal with tmux running inside (no scrollbars, tabs, menubars, etc) and it works for me.
At some point, every application (browser, terminal, tmux, ...) re-implementing their own version of tabs is kind of silly.
Ideally "look at 'window' X of application Y" (where window == window / terminal tab / tmux pane / whatever) is what the local window manager should be used for.
E.g. instead of 1 tmux session with 4 tabs in it (or 1 terminal window with 4 tabs in it), I will run 4 mosh/tmux sessions (or 4 terminal windows) with 1 tab each, and use my regular window manager commands (i3) to switch between them.
In theory this is a better separation of concerns, and I can have one set of key bindings to do all window switching. Not:
1. Use window manager keys ctrl-foo to get to the right desktop/terminal window 2. Use terminal keys ctrl-bar to get to the right terminal tab with my tmux session in it 3. Use tmux keys ctrl-zaz to get to the right tmux pane
(Obviously a contrived example.)
...that said, I still use a crap load of tabs in Chrome, so theory != practice.
All I need is an orthogonal solution for persistent shells (how about I persist arbitrary login process trees, graphical or textual, OK?) And I'll truly have no need for tmux.
Then again I don't ssh too often for too long, so the last part is endlessly low priority.
Anything with more features I probably wouldn't use, either.
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.
I hadn't replied to this because others had already provided all of the info I have. To summarize, the author of notty[0] and I are talking about a collaboration[1]. notty has done a ton of pathfinding in this area on identifying how to add many of these features in a backwards compatible way. I'm really looking forward to see where it goes!
[0]: https://github.com/withoutboats/notty [1]: https://github.com/jwilm/alacritty/issues/51
1) TERM is broken: https://www.facebook.com/notes/daniel-colascione/term-is-ter...
2) We need to start adding capabilities to terminfo again --- see the incredible mess in bracketed paste support, true color support, etc.
3) TIOCSTI is a giant truck-sized security hole. We need to stop supporting it.
Or I suppose use terminfo, but I like the idea of dealing with text streams better.
Your last paragraph suggests what you really want is a notebook style interface (in the style of mathematica) rather than a terminal.
Hah, yeah I'm aware, but the potential of Rust is huge.
We talk a lot about open source these days, but meanwhile the tools that we all use are sitting on huge substrates that the vast majority of us aren't contributing to and probably never will due to the complexity hurdle that needs to be overcome.
This includes our web browsers, our terminals, our editors/IDEs, our operating systems, our security software (OpenSSL, NaCL, OpenSSH), and if you're a developer, things like our databases. Although I can ostensibly write C and C++, I still don't contribute to these projects because oftentimes a whole new set of local conventions around build tools and utility libraries needs to be learned for every project, and there's a high bar of experience required before contribution is possible without the risk of introducing a memory leak or security problem.
Rust has the potential to change all of this, and that's really, really big.
> Your last paragraph suggests what you really want is a notebook style interface (in the style of mathematica) rather than a terminal.
I definitely appreciate Mathematica and its sort of rich prompt is probably closer to what a terminal should look like rather than what we have today. But most of what I'm doing all day is text editing and using companion tools like Git, which isn't a good fit for it. I'd much rather that those Mathematica utilities come to my terminal rather than me having to go to Mathematica.
Interesting.
I stay in textmode. Hence I do not need an emulator.
If I need graphics I access the files over VLAN from another computer designed for mindless consumption of graphics, like the locked-down ones they sell today with touchscreens, etc.
My understanding is that emulators like xterm can redraw the screen faster than VGA. I remember this can make textual interfaces feel snappier.
But I doubt that jobs execute any faster in X11/Wayland/whatever than they do in textmode. I cannot see how the processes would be completing any sooner by virtue of using a graphics accelereted emulator.
But I could be wrong.
I sometimes use tmux for additional virtual consoles because on the computers I control (custom kernel, devices and userland) I do not use multiple ttys, just /dev/console.
I rarely ever work within tmux. I only use it to run detached jobs. I view screen output from my tty with something like
case $1 in -B|-E|-S|-t)
tmux capturep $@ --
exec tmux showb $@ --
esac
Not sure why I would ever need these slow "web apps".
I guess the third parties controlling the endpoints might be able to utilise the data they gather about users. And I am sure some users appreciate the help. Thus it is a symbiotic relationship.
I am continually making my "tooling" faster by eliminating unecessary resource consumption. It is an obsession of sorts. Constant improvement.
But given that I am working with text, graphics processing is not something I need. I would not mind being able to run my non-graphical jobs on a fast GPU, but my understanding is that the companies making these processors are not very open. For example, the GPU in the RasperryPi.
Always interesting to hear how others are meeting their computing needs.
I don't think there's anything out there in the that matches the volume of deployed HTML, CSS and JS in the wild.
The horribly sad part is that HTML, CSS and JS are a gigantic Rube Goldberg implementation of "run arbitrary code in a safe sandbox," because the Web is also the world's biggest collection of legacy dependency.
IMHO, the source of the engineering cringe making everything so much sadder and less than what it could be is that the W3C/WHATWG/IETF/etc are made up of consortiums of large, foghorn-equipped corporations - corporations that have vested interests in advertising, consumer retention, and strong guarantees of indefinite consumption.
I've never really gotten the reasoning behind the technical directions the Web's gone in; a lot of things have stuck and worked, but so many more have flopped, yet the associated implementations for both the successes and failures have to be maintained going forward indefinitely.
The iterative pace on the various Web standards is another problem - things go so fast that the implementations can never get really really good, and Chrome uses literally all of your memory (whether you have 2GB or 20GB, apparently!) as a result.
---
Regarding $terminal_emulator being faster than VGA, I can emphatically state that virtually all of them are disasterously slow. aterm had some handcoded SSE circa 2001 to support fake window shadowing (fastcopy the portion of the root window image underneath the terminal window whenever the window is moved; use SSE to darken the snagged area; apply as terminal window background) but besides that sort of thing, terminal emulators have more or less never been bastions of speed.
If by VGA you mean true textmode (the 720x400 kind, generated entirely by the video card), I don't think there's much that's faster than that. Throw setfont and the Cyr_a8x8 font in there to get 80x50 (I think it is, or 80x43) and you have something hard to beat, since spamming ASCII characters at the video card's memory will always be faster than addressing pixels in a framebuffer.
Which is why GPU-accelerated terminal emulators are so interesting: they're eliminating as many software/architectural bottlenecks as possible to make those expensive framebuffer updates as quick as possible. It's definitely the way to go; games are generally rated on their ability to push GPUs to >60fps at 1080p (and increasingly 2K/4K/8K), so the capacity is really there.
The i3 window manager could be considered one of many comparable similar implementations to tmux. It's not perfect (it's not as configurable as I'd prefer), but it'd get you X and the ability to view media more easily.
I do really appreciate the tendency to want to view a computer as an industrial terminal appliance though. Task switching is still best done by associating tasks with different objects in physical space, so keeping the computer for terminal work and keeping tablets (et al) for other tasks does make legitimate sense.
---
Regarding data usage, that's a tricky one - most successful Internet companies provide some kind of service that necessarily requires the collection of arguably private information in exchange for a novel convenience. As an example, mapping services don't truly need your realtime location but having that means that they can stream the most relevant tiles of an always-up-to-date map to you. The alternative is storing an entire world map, or subsetted map(s) for the locations you think you'll need, but that'll kill almost all the storage on phones without massive SD cards.
---
I find elimination of unnecessary resource consumption a fun concept to explore, almost to the point of obsession. In this regard I often come back to Forth. I was reading this yesterday - http://yosefk.com/blog/my-history-with-forth-stack-machines.... - and it explores how Forth is essentially the mindset of eliminating ALL but the smallest functional expression of the irreducible complexity of an idea, often to the point of insanity. It's not a register-based language so it's never going to beat machine code for any modern processor, but it's a very very interesting concept to seriously explore, at least. (And I say that as someone interested in actually using Forth for something practical, as described in that article.)
---
AFAIK, the RPi actually boots off the GPU, or at least the older credit-card-sized ones did. I'm not sure about the current versions.
ATI released some documentation about their designs a while back with the subtext of enabling open-source driver development. I don't think that panned out as much as was hoped.
My understanding is that Intel has both NVIDIA and AMD beat nowadays when it comes to Linux graphics support; the two former vendors still heavily rely on proprietary drivers (on Linux) for a lot of functionality.
Sadly, since they both have to successfully compete in the market, they're unlikely to release their hardware designs in significant detail anytime soon. (Even if they did like the idea of merging, single gigantic monopolies have a lot of risk, and the behemoth that resulted would be impossible for Intel to compete with, likely.)
So, learning OpenCL and CUDA (depending on the GPU you have) is likely your best bet. There are extant established ecosystems of resources and domain knowledge for both implementations, and the relevant code is not too tragically licensed AFAIK.
It might be super fast, but I've not really been scroll speed limited.
On Windows I use mintty and I turn off scrollbars there. I simply don't use the mouse to interact with the terminal other than to select text, and that's with selection buffer to copy.
Speed is highly relevant to me. Most modern terminal emulators are very slow, most noticeable when you get a lot of output in a panel in something like tmux.
(Simplistic benchmarks that test full screen scrolling usually hand the crown to terminals that don't bother to refresh the screen with everything output, but that's not the only bit of a terminal emulator that can be slow.)
Point is, that stuff is easy to add in subsequent releases. Its an early project. Give it time to become.
Early Alpha concentrates on stability before bells and whistles. Agree though scroll bars would be nice but patience.
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
I downloaded the nightly within a minute, and I compiled a release within 125 seconds. Immediately after I changed back to stable. It took two cli commands to swap between. NPM couldn't get all my packages for my React crud app that quickly.
One thing that Rust really seems to be doing right is tooling whether it be Cargo's package and compilation management or Rustup's toolchain management, and their 2017 roadmap is pretty much entirely about tooling: https://github.com/rust-lang/rfcs/blob/master/text/1774-road...
I didn't remove the dependency on proc_macro since that stabilizes in the next release and I'm lazy (if someone else wants to try, go for it!)
> 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
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.
In this specific example, I saw that building the project required mucking with my rust version/setup and decided that the cost of that was too high for me to proceed. Totally possible that I mis-evaluated the cost, but that was what happened in my head.
I don't at all mean to tell you what is best, I do think highly of your project and wish you all the success.
I forget the precise details, but I believe this was required for using newtype wrappers as a `Range` for indexing. Specifically, the grid can be indexed as a range like
grid[Line..Line]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.
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://github.com/GNOME/vte/blob/b517d20379c7a665e897f925ca... line 10685
I'm building a 3D game in Rust and would like to be able to drop this in.
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
+100 :}
dpi:
x: 144.0
y: 144.0
One other feature that's a killer for me is being able to change the font size while running -- ctrl++/-.
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.
Looks like most for FFI, but there's some other small bits too.
At 80x24:
gnome-terminal:
real 0m0.848s
user 0m0.032s
sys 0m0.072s
real 0m6.832s
user 0m0.032s
sys 0m0.164s
gnome-terminal:
real 0m0.819s
user 0m0.020s
sys 0m0.088s
real 0m8.972s
user 0m0.064s
sys 0m0.164s
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.
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.
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.
EDIT: Ah, after a little sleuthing, the recent post from OneSignal on why they chose rust for one of their services makes sense :).
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.
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,
I tried this too. `$ find /Applications` iTerm2 - 0:26 Alacritty - 0:12
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_
> 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.
edit: or it did but now its going to the website.
Nice work. Hopefully this can fill a particular void for folks that want no-frills fast terminal emulation.
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.
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.
> 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
(That is, that project is GPL licensed, and they didn't want that)
When does this slowness show itself?
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.
So I guess we all need a faster term emulator :)
Some terminals bottleneck standard out ️ display , some hardcode the display rate
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?
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
thread 'pty reader' panicked at 'cursor fell off grid', src/term/mod.rs:634 find ~
iTerm2 1m20s
alacritty 47s
iTerm 130% (peak up to 140%)
alacritty 25% (peak up to 29%)
The lack of scrollback/tabs/etc doesn't bother me at all - I use tmux for this exactly as suggested.
Thank you for this!
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 :)
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.
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!
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.
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.
Thanks!
"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."
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.