Ticket #3145 (new enhancement)

Opened 10 months ago

Last modified 2 months ago

Support for True Color (16 millions colors)

Reported by: akochkov Owned by:
Priority: major Milestone: Future Releases
Component: mc-tty Version: master
Keywords: Cc: egmont@…
Blocked By: #3264 Blocking:
Branch state: no branch Votes for changeset:

Description

Now more terminals bring support for 16 million colors (see references below).

Here's a test case for terminal:

printf "\x1b[38;2;255;100;0mTRUECOLOR\x1b[0m\n"

It's a common confusion about terminal colors... Actually we have this:

  • plain ascii
  • ansi escape codes (16 color codes with bold/italic and background)
  • 256 color palette (216 colors+16gray + ansi) (colors are 24bit)
  • 24bit true color (8*8*8 colors (aka 16 milion)

The 256 color palete is configured at start, and it's a 6*6*6 cube of colors, each of them defined as a 24bit (8*8*8 rgb) color.

This means that current support can only display 256 *different* colors in the terminal, while truecolor means that you can display 16 milion different colors at the same time.

Truecolor escape codes doesnt uses a color palete. It just specifies the color itself.

[1] https://en.wikipedia.org/wiki/ANSI_color

Here is terminals discussions:

Now supporting truecolor:

Not supporting truecolor:

P.S. Also sent email to the S-Lang library developers

Attachments

slang-truecolor-demo.patch (8.6 KB) - added by egmont 10 months ago.
mc-truecolor-demo.patch (2.3 KB) - added by egmont 10 months ago.

Change History

comment:1 Changed 10 months ago by akochkov

  • Component changed from mc-core to mc-tty

comment:3 Changed 10 months ago by egmont

Slang thread: http://lists.jedsoft.org/lists/slang-users/2014/0000002.html
Ncurses thread: https://lists.gnu.org/archive/html/bug-ncurses/2013-10/msg00007.html

I'd be happy to work on true color support (btw I was the one adding 256 colors in #2169) if I knew how to do in slang and ncurses - but it seems to me that at this moment neither of them provides support.

Last edited 6 months ago by egmont (previous) (diff)

comment:4 Changed 10 months ago by egmont

  • Cc egmont@… added

comment:5 Changed 10 months ago by egmont

Note: I have a feeling that the 256 color support isn't as popular as it could be. Probably skins are not as popular in general, most people just use the default. This might be due to the lack of a runtime skin selector (#2165).

We've had 256 color support for about 3 years. In addition to the demo skin I created (which I still use every day, but haven't heard from anyone else :)) we ship only 2 more (one of them having a few minor variants), and I couldn't find other ones on the Internet either.

True colors could give a boost, it surely would be a cool feature, but it won't save the world :)

comment:6 follow-up: ↓ 7 Changed 10 months ago by ossi

i would say the reason is that 256 colors just aren't all that useful in a TUI. by extension, TrueColor? seems like the most useless feature one could add to a terminal ever.

comment:7 in reply to: ↑ 6 Changed 10 months ago by akochkov

Replying to ossi:

i would say the reason is that 256 colors just aren't all that useful in a TUI. by extension, TrueColor? seems like the most useless feature one could add to a terminal ever.

I can't agree with you. Especially if you're working mostly in console programs (like I am e.g.), you will need to make it beautiful (from your point of view of course), as much as possible.

comment:8 Changed 10 months ago by egmont

ossi: Let me try to challenge you. In enlightenment's terminal you can - from command line - specify a background video to play. Do you still think true color is the most useless feature? :D :D :D

I think I get your point, true color (opposed to 256) is on one hand "why", on the other hand "why not"... For me, "why not" is slightly stronger.

comment:9 Changed 10 months ago by ossi

that background video thingie doesn't need the true color for the actual terminal function. just sayin'. ;)

the thing is that the factual resolution of a terminal (and even more the applications it offers) does in no way enable you to make use of 16.7 million colors at the same time (it's quite unlikely that you have much more than 20k cells available to start with). even 256 colors at the same time is a bit of a challenge (i guess a different shade for every file type can get you there).
given that true color doesn't come for free (assuming a linear frame buffer of aligned structures, it doubles space requirements from 8 to 16 bytes per cell), and i *really* like my virtually unlimited scrollback, the "why not" seems pretty obvious to me.

comment:10 Changed 10 months ago by egmont

I didn't imply any correlation between true colors and bg video, just mentioned something for fun that is IMO way more useless ;)

There's no point comparing the number of character cells to the number of available colors. My whole desktop is less than 16M pixels, still I have access to 16M colors. The point in terminal is not to use all of them at the same time, but to use any of them at any time.

I personally started using Linux and terminal in '96 (using X window of color depth 8, always changing colors so that only the focused window was displayed correctly, probably the worst user-unfriendly compromise I've ever seen). Since then, CPUs became at least 20-fold faster (and that's just the clock speed, so I'd bet 100-fold or similar), RAM installed became almost 1000-fold larger. Way back then, storing a character cell required probably 3 or 4 bytes. (8-bit encoding, but additional line drawing characters were already available, so that's more than 8 bits for the character, plus 9 fg + 9 bg colors (8 + default), bold, probably reverse, underline and blink were supported too, I'm not sure). Now the super wasteful way of storing would be 16 bytes, meaning an at most 5.33-fold (but probably much smaller) growth during this time period.

I see no reason why any terminal would store a cell in 16 bytes (4 unused) instad of 12, any access to the scrollback content is followed by drawing on the screen, compared to that the price of reading from nonaligned offset is negligible. As a matter of fact, using 12 bytes per cell is also a total waste. I don't know how terminals other than VTE store their scrollback content, I only know about VTE (gnome-terminal). For the onscreen part it uses the obvious way: records of 12 bytes; whereas for the scrollback it uses UTF-8 character stream, and a runlength encoding of identical attributes (that is, a record of 16 bytes consisting of an offset (8 bytes) where the attribute changes, and 8 bytes encoding the true colors and other attributes). In the worst case scenario (attribute changes in every cell, and 4-byte UTF-8) it's 20 bytes for a cell, but typically much less than that, usually (English text and no color change) it's just 1 byte. Other approaches might include compression of the scrollback, or whatnot. Software engineers have solved way tougher problems than this. If any terminal emulator is using 12+ bytes per cell and you think it's too much, please file them an enhancement request.

That being said, this discussion here is pretty pointless. If you have serious concerns, it should be brought up with terminal developers. Quite a few terminals already support true colors, probably some others will follow too. Once ncurses/slang makes this feature available for mc, I'll be happy to add support, it won't hurt anyone and this step definitely won't increase the terminal's memory usage. My current skin (sand256) was a heavy compromise between what I had imagined and what I could reach using the 256 colors. With true colors I'll be able to implement exactly what I imagine - this doesn't sound like a useless feature to me after all :)

Changed 10 months ago by egmont

Changed 10 months ago by egmont

comment:11 Changed 10 months ago by egmont

I attached demo patches that let you use true colors in MC (using a patched Slang).

On 32 bit machines the Slang patch breaks the ABI compatibility. This means that you shouldn't replace the system wide Slang, or else I'm afraid all applications using Slang will break. You should also take care to compile MC against the patched Slang header files.

On 64 bit machines there's no such issue, Slang remains ABI compatible with the unpatched version, and it's okay to compile MC against the system-wide Slang headers.

In either cases I recommend to install the library under some experimental location, and use LD_LIBRARY_PATH or other similar mechanism to make the patched MC use that version instead of the system wide.

There's no terminfo support yet, so the Slang patch doesn't even try to verify if the terminal has support. It just uses hardcoded escape sequences. (Well, maybe it verifies that more than 8 colors are available, so set TERM=xterm-256color or similar.)

The MC patch is really minimal, it's basically just that it doesn't reject the new color names, and knows how to create a canonical string representation that is used as a key in a table. The actual interface to Slang uses color names (strings), and didn't change at all.

After applying the patches, you can start using standard #rrggbb-like color names in addition to the currently available ones. Short #rgb names are also accepted (e.g. #abc is the same as #aabbcc). Additional color names, such as the ones available in HTML or in X Window, are not supported.

Anton, if you take time to create a beatiful truecolor skin, I'd be happy to see it :)

Last edited 10 months ago by egmont (previous) (diff)

comment:12 Changed 9 months ago by dickey

I overlooked this item yesterday, but added it to my summary.

http://invisible-island.net/ncurses/ncurses.faq.html#xterm_16MegaColors

comment:13 Changed 2 months ago by egmont

  • Blocked By 3264 added
Note: See TracTickets for help on using tickets.