Notes on photo sphere/panoramic EXIF metadata

/ Tags: Photo.

The woes with terminal emulators

Generally I use xterm because that is available on about every UNIX workstation, or where not, “derivates” (allow me to use this terminology even if it may not apply) like rxvt are available on, for example, MSYS (system around MinGW for Win32). However, I wanted to try something different, as xterms only seemed support bitmap fonts (I later found out that it can use freetype).

In the course of having tried all the terminal programs, a set of criteria seemed to have emerged:

libvte deserves a separate section here, because some terminals make use of it. Since libvte happens to have some bugs in the version I had installed (0.17.4), terminals making use of it are affected. Bug report is pending. Let's see where this goes. (Probably nowhere as usual.)

libvte suffers from a some cosmetic issues, making it hard to use my favorite editors because either the cursor suddenly disappears (blue-on-blue) or the background does not get painted thoroughly (read: correctly).

Both sakura and gnome-terminal which make use of libvte will cause a high CPU use. While the terminals hum along between 3–6%, the X server process rises up to as much as 52%. (Window size and font is the same as Xterm, for a fair comparison.)

Sakura was the first new terminal emulator to try; the reason for it being the first is probably because I had probably heard/read it some time back and it stuck in the head.

Since most of the job is done by libvte, there is not much to write, really. What was of note is that sakura (version 2.3.2) did not allow me to change the palette to custom colors and that there was a geometry (window size) related bug (said to be fixed in 2.3.3).

Over sakura, gnome-terminal allows changing to custom colors. Contrary to slowness warnings from people on IRC (outside #gnome), it is not any slower than anything else libvte-based.

Given the problems libvte currently has, I sought ought for a terminal that does not seem to use it, judging from ldd output. KDE came to mind...

Turns out you cannot even select non-monospace TTF fonts. And as it stands, Latin Modern Mono seems to not have classified itself as monospace, so I could not select it. Also, kde-konsole is horribly slow, the konsole process taking up 21% CPU, and X also its 52%.

I also tried roxterm; it was indistinguishable from gnome-terminal actually. Also uses as much CPU.

Conclusion: Xterm has so far been the most flawless terminal.

Color coherence is really needed when you want to write top-quality source code. If your cursor just disappears as it does with libvte, you need to relocate it using alternate methods, like row/col number of arrows on the side rulers (if such exist in the particular editor).

Xterm's speed is described by its CPU usage when scrolling through a text file — 1.3% to 3.7% according to `top` and, above all, the X server process stays calm during scrolling.

Remark 2011-Nov-23: repaint-ok means whether BCE is done (paint background with color on erase). BCE occurs on the VT console (among others) when you emit the sequence \e[44m\e[2J (set background to blue, and clear entire screen).

Name Unicode CJK free choice of
bitmap/ttf fonts		 customize
colors		 “repaint”
ok?		 fast (term/X cpu%) glyph
spacing ok?
Xterm 236 ✓ ✓ ✓ ✓ ✓ ✓ ✓, 3-6%/<3% ✓(having to set it manually, but ok)
sakura 2.3.2 ✓ ✓ ✓ ✓ ✗ ✗ ✗, 6-7%/60% ✓
gnome-terminal 2.24.1.1 ✓ ✓ ✓ ✓ ✓ ✗ ✗, 3-6%/52-55% ✓
kde4-konsole 4.1.3 ✓ ✓ ✓ ✗ ✓ ✓ ✗, 20%/50-55% ✓
Eterm r38808 ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✓

Fonts

Notes

“Rulers - if such exist in the particular editor”: the text editing tool “GFA DeskPlus” (1988) employed a ruler at the bottom of the screen, and I ported this feature to mcedit for my own convenience (and not because the cursor disappeared).

DeskPlus word processor mcedit with deskplus ruler

Posted 2009-02-14 01:02 / Tags: Linux. / link