3 ms·

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

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