On Tue, Apr 25, 2017 at 9:55 PM, <tu...@posteo.de> wrote: > Hi R0b0t1, > > On 04/25 02:15, R0b0t1 wrote: >> On Tue, Apr 25, 2017 at 10:47 AM, <tu...@posteo.de> wrote: >> > 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. >
If your system doesn't support python 3 then that is arguably the larger problem and you should get it fixed before you are *forced* to get it fixed when support is dropped. >> >> 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? > I'm not exactly sure what timing something *inside* the terminal will accomplish, as it's very possible that all writes will be passed to buffered, memory mapped areas. In essence all that would be timed is the system calls and any time the programs spend processing their input, not anything that the terminal emulator has any control over, like rendering and scrolling speed. In any case try running the tests a few times to see if the files (including the executables) are cached and the operations complete more quickly. If terminal emulators differ in anything but their rendering speeds I would be extremely surprised, as that is really all they do. The suggestion to look for compositing is a good one. I suggest the useflags "egl gles gles2 opengl" (or some variation of that) to make sure acceleration is enabled for every program that can use it. As an aside, the above useflag changes and some others are on a list of things I think should really be added to the handbook - they're basically essential for a usable system on most hardware now. >> > 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. > If you can't come up a very specific feature list you will have to resort to trying programs yourself. Otherwise, it looks like all of them qualify. On Thu, Apr 27, 2017 at 9:02 AM, Grant Edwards <grant.b.edwa...@gmail.com> wrote: > On 2017-04-27, Guy-Laurent Subri <guy-laur...@subri.ch> wrote: > >> Here's the link to the website: http://st.suckless.org/ >> And here's also a link if you want other terminals that support >> truecolors : https://gist.github.com/XVilka/8346728 > > I'm curious what true-color support actually _does_ in an ANSI > terminal emulator. The ANSI escape sequences only allow for 16 > colors. > It extends the emulator with nonstandard control codes. You specify RGB values directly with printable characters.
