Topic: Terminator too slow

I'm having a problem with terminator lately which only happens when resizing it to over roughly 3/4 of the whole screen height. It's becomes pretty slow in terms of terminal scrolling (independent from font size/how many lines are on the terminal). I'm not sure why this happens, but often in apps like Joe and man which scroll line by line rather than by page like nano. xterm on the other side works fast like wonder, so I guess it isn't simply due to a too slow computer but due to something inside terminator. My first idea was the font, xterm uses one with fixed height (maybe a bitmap font?) and is thus faster in rendering. But do get I get the same results in terminal even with very small font sizes? Nope, it doesn't matter. It only happens in terminator and only when it's window is big enough.

It must be something I can't systematically detect. Anyone any ideas? I don't want to use xterm, it is rather limited (I love terminators splitting ability) and it's font is rather not suitable for editing code imho...

Also, if it's a problem of slow hardware, I'm running it on an IBM T30 with P4 2.0 Ghz, 512 MB RAM, 1024x768. CPU usage goes up to 90% when scrolling in terminator and a maximum of 50% in xterm.

Re: Terminator too slow

Hi Kekskiller,

have you changed something in ~/.config/terminator/config ? Maybe you want to put the output of the file here.
By the way, xterm's settings could be changed in .Xdefaults in your home folder, AFAIR fonts can be changed there, as well as the colour scheme.

Let's all get forked.

Re: Terminator too slow

Hm, I didn't really change anything to the file. However, here's it's content:

# Terminator config, see "man terminator_config" for more options
# ---------------------------------------------------------------
scrollbar_position=disabled
force_no_bell=true
background_color=#000000
foreground_color=#FFFFFF
font=Mono 9
palette=#2E2E34343636:#CCCC00000000:#4E4E9A9A0606:#C4C4A0A00000:#34346565A4A4:#757550507B7B:#060698209A9A:#D3D3D7D7CFCF:#555557575353:#EFEF29292929:#8A8AE2E23434:#FCFCE9E94F4F:#72729F9FCFCF:#ADAD7F7FA8A8:#3434E2E2E2E2:#EEEEEEEEECEC

# Uncomment below to enable transparency
# --------------------------------------
#background_type=transparent
#enable_real_transparency=true
#background_darkness=0.8

Will also take a look at .Xdefaults.

Edit: While reading this article I got the idea that it might have to do with memory allocation or buffer management. Maybe terminator is a bit slow if it comes to that? Has anyone similar experiences with older laptop RAM?

Edit2: Well, using the benchmark method he was using only reveals how slow xterm is in terms of writing large texts to it's buffer. So it isn't really the problem.

Last edited by Kekskiller (2010-08-02 16:48:38)

Re: Terminator too slow

Hm! Two and a half other thoughts:
- Have you changed or extended your .bashrc file? Or run a very large file of aliases?
- Does this only happen with enabled compositor (transparency, fading, shadows enabled)?
- What about an upgrade of terminator from https://launchpad.net/~gnome-terminator/+archive/ppa ?

Let's all get forked.

Re: Terminator too slow

No changes to .bashrc, compositing is off (font antialiasing, too. was just too slow to render), almost no aliases.

Will test the upgrade. Well, I still think it's its java-ish garbage collecting that may happen between every rerendering/scrolling. In this case I better get another shell. Which would be too bad cause terminator's ability to split windows is imho far better than tabs.

Re: Terminator too slow

in this case GNU screen with splitting: http://www.linuxjournal.com/article/10159 big_smile

Let's all get forked.

Re: Terminator too slow

That GNU screen thing sounds interesting, machinebacon. Well, I just replaced terminator with Eterm which a bit more readable than xterm (I think they they use the same font, but Eterm translates white text to grey and bold text to white, so you don't get such cramped characters). I'll try to get GNU screen working for me, should be worth getting used to get.

This isn't solved yet, cause terminator is still slow, but atleast I found another solution working well.