Image of it in action:

From the CI logs it looks like allsorts does not support the MSRV of alacritty. What do you think is the best action here @chrisduerr?

@perfbot

Why did you pick allsorts over a library that is actually reliably tested?

Because allsorts is rust native. It removes the need of a third party FFI crate, so no FFI overhead and it is cross platform. If you would prefer using Harfbuzz, then I can switch over to Harfbuzz, but I am no expert in coretext and uniscribe to be able to easily come up with a windows/mac support.

Would you like me to open another PR that uses harfbuzz to compare their performance?

Would you like me to open another PR that uses harfbuzz to compare their performance?

I think as the person proposing this change, you should test the performance implications of different solutions. And I'd like to point out that the previous test only verified potential PTY lock contention issues, while the change itself will most likely impact framerate. So to actually verify the performance of these benchmarks one must record the rendering framerate.

Because allsorts is rust native.

That seems more like an argument for laziness rather than picking the correct solution. As far as I'm aware there's basically nobody using allsorts; it's a new library without a lot of development time behind it that has largely dried up over the past 4 months. So all things considered the argument really should be made why not to choose the reliable standard Harfbuzz that has been tweaked wrt API stability and performance for decades.

Oops, I retract that comment, that was a bad mistake. I forgot to build with release mode.

EDIT: to be honest there is not much of a difference to me. I couldn't tell the difference between allsorts and harfbuzz and no shaping

EDIT: to be honest there is not much of a difference to me. I couldn't tell the difference between allsorts and harfbuzz and no shaping

Define "tell the difference". You shouldn't have to try and tell anything, benchmarks should always be measured in metrics that can be tracked and compared against each other. So either there is a framerate difference or there isn't. Also of course since vsync might limit the framerate, one should ensure to decrease the font size until Alacritty starts struggling since ultimately that's where this starts to matter.

I'd personally assume that Harfbuzz outperforms Allsorts, I think one of the contributors to Allsorts has told me that before. But one still needs to actually compare the numbers directly to see how much it would differ.

That is not a benchmark lol. Calling it a rough estimate would probably still give it too much credit.

I still have the binaries. I am not really familiar with measuring performance of terminals. Could you please provide with some instructions or tools to generate data with? Thank you.

Benchmarking workloads are part of Alacritty's contribution documentation, measuring framerates depends both on your hardware and software so you'll have to figure that out on your own (though it's likely the more relevant piece of information here).

Hello, I'm back.

typometer

vtebench

framerate

I used mangohud to observe the framerate of cat /dev/urandom on wayland with font size set to 1. The MangoHUD program does have a logging option but it is unavailable under wayland. Running cat /dev/urandom on Xorg unfortunately freezes the X server so I had to observe the average via human eye.

Baseline (no shaping, commit before either change): ~17.1 ms, 58 fps on average

Shaping with allsorts: ~32.1 ms, 31 fps on average

Shaping with harfbuzz: ~23.4 ms, 42 fps on average

binary size

EDIT: based on ldd it looks like harfbuzz is dynamically linked. this comparison is meaningless.

$ ls -al alacritty_* | awk '{ print $(NF)"  "($(NF-4))" bytes" }'
alacritty_allsorts  35448344 bytes
alacritty_baseline  32224528 bytes
alacritty_harfbuzz  32291456 bytes

I think the overall assessment is that harfbuzz is superior.

That rendering performance seems awful for both harfbuzz and allsorts, considering that the baseline is probably only at 60 because it's limited by vsync. And that's with a trivially slow benchmark like cat /dev/urandom.

Well, at least we know which library to choose. I'll try to improve performance with harfbuzz.

Also, note that cat /dev/urandom is probably biased against shaping engines because they output a lot of characters that shaping engines don't recognize. That means fallback paths will be executed more often than a daily use scenario.