A look at terminal emulators, part 1 [LWN.net]

A look at terminal emulators, part 1

Posted Apr 4, 2018 13:20 UTC (Wed) by borisfaure (subscriber, #123474)
In reply to: A look at terminal emulators, part 1 by grawity
Parent article: A look at terminal emulators, part 1

(I'm Terminology's main developer.)

Terminology does not support RTL scripts, but there's a bug open about it: https://phab.enlightenment.org/T5380 .
It does support Unicode but not combining characters (https://phab.enlightenment.org/T560). The test in the article should render correctly though.

I have not refused to add a true-color mode.
It won't support it fully but it does approximate those TrueColors to a palette of 256 colors. It should do it better than XTerm since it is not using a dumb euclidean distance to compute color distance but something a bit more complex: the last formula on the Euclidean chapter on Color Distance on Wikipedia ( https://en.wikipedia.org/wiki/Color_difference#Euclidean ).
I know it's not perfect but having true-color support would imply too much work on EFL and I'm not confident on doing that soon. As usual, I'll be happy to review patches!

I'd also be interested in benchmarks. On the ones I used, Terminology was a clear winner few years ago.

to post comments

A look at terminal emulators, part 1

Posted Apr 17, 2018 20:18 UTC (Tue) by Ross (guest, #4065) [Link]

XTerm supports using the full range of non-paletted visuals if you compile with --enable-direct-color.

But that's an interesting point about color distances.

XTerm doesn't just use Euclidian distance. It's kind of messy. See allocateClosestRGB() for allocations and searchColors() for finding matches.
xtermClosestColor() does work as you suggest when matching colors on a paletted display (or if not compiled with DirectColor support). find_color_register() for graphics uses weighted Euclidian distance, and it doesn't seem to take advantage of DirectColor (that's my fault).

I'd immediately replace all of these, but there are two problems with the CIEDE2000 formula:

* it most likely assumes linear response per channel -- this is usually not true with raw RGB
correcting for this is either a lookup table per channel (but it is hard to know which values to
plug in) or it isn't clear how to adapt the formula

* the formula would be very slow as they would require colorspace conversion in addition
to lots of multiplications, divisions, and square root operations in the computation itself

The last formula in the Euclidian section which you mention looks reasonable, but the first issue
probably still applies. How do you handle that? How much better is it than the weighted Euclidian
distance? It would be nice to have a way to measure match quality to test various approximations.