Re: [gentoo-user] In search of an truecolor-capable terminal emulator

Hi R0b0t1,

On 04/25 02:15, R0b0t1 wrote:
> On Tue, Apr 25, 2017 at 10:47 AM,  <tuxic@××××××.de> wrote:
> > Hi,
> >
> > currently I am using urxvt as my standard terminal
> > application, which is FAST and reliable.
> > But it only emulates 24bit colors if instructed so.
> > It maps 24bit rgb to 256 color using a fast but not
> > total correct formula to to do (which is no critism -
> > its just the way ot is implemented).
> >
>
> I suppose you have seen https://gist.github.com/XVilka/8346728, but if
> not, I will link it for you. Anyone following along who hasn't read it
> might be inclined to do so.

Yes, I found that before. It triggers my post here and asking
for experiences... ;)
>
> > I googled qyite a bit to find 24color terminal
> > emulators and the one, which came closer to
> > what I want is sakure.
> > But comparing the speed of sakura with urxvt
> > (catting a long log file twice while measureing the time
> > of the second cat) it shows that sakura needs
> > six times more time than urxvt.
> >
> > Combining this with the compile sessions, which
> > are one of the core features of Gentoo ;)))...
> >
>
> I would suggest looking at:
> *) https://github.com/jwilm/alacritty
> *) https://github.com/kovidgoyal/kitty

I tried alacritty before ... or better: I tried to solve
all dependencies and stopped at a certain point because
it got all too ... how should I call that.... fuzzy?

Kitty needs python3 ... I am on python2.
Last time I got in conflict with these pythons I finally
had to decide to reinstall my Gentoo from ground up 
(others things were also a reason, so not to blame
python alone).
So I stopped here also.

>
> Both of which are OpenGL accelerated. Unfortunately I'm not entirely
> sure why sakura is slow. Finding out might be worthwhile. Alacritty is
> the shiniest, but unfortunately the rust build and setup process looks
> very insecure, similar to Haskell. Take into account that those
> languages are experimental.

I tried xfce4-terminal as suggested by Floyd...and got exactly the
reversed timings. He found xfce4-terminal six times faster than
urxvt and I got the reversed result.
If I could find the culprit on my box I would be happy with sakura
and/or xfve4-terminal.
Where can I start?
What may be the reasons?

> > What I want is the "fastest" possible (...)
> > terminal emulator supporting true color (24bit).
> > I dont need fancy configuring options (two exception:
> > TABS! and lightweighted) and I dont want KDE stuff (or
> > any other bloated thing with thousands of dependencies...)
> > I am simply using openbox.
> >
>
> Tabs are probably a stretch though I admit they are a useful feature.

I dont like to insert just another layer of confusion ;) with
my terminal like screen of tmux. They are fine for in special cases
but for my daily tabbed terminal I would like to have native support
rigth in the terminal emulator.

> I would recommend that if you find a Desktop Environment that has a
> program you like you simply use it though the look may clash with your
> other programs. It's hard enough to find programs that do what you
> want on Linux.

I have no problems with the 'optical clash'. But I don want to
pull in dozenz of dependencies (KDE) just for a terminal emultor.
These will also increase the amount of stuff which needs to be
updated...

> > What are your experiences?
> >
>
> Nothing really seems to do what I want, and that may translate into
> nothing really doing what you want.

...or in other words: I need to find the reason, why some terminal
emulators are slow on my box and not on others...

> > Any hint is heartly welcome! Thanks !
> >
> > Cheers
> > Meino
> >
> > PS: The terminal emulator dont need to be part
> > of Gentoo necessarily...if it is compilable
> > by a human being withoyt super powers... ;)
> >
>
> Check the list on that gist - may as well keep trying them until you
> find one that you like.

To prevent exactly that was the reason for asking for experiences
others made with terminal emulators.
Blindly following the compile-install-test-desinstall cycle with
applications listed somewhere is not efficient.

Cheers
Meino