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

[Floyd Anderson]

On Sa, 29 Apr 05:15:50 +0200
tu...@posteo.de wrote:


Hi,

before changing my system I took a look at
https://wiki.gentoo.org/wiki/Xorg/Hardware_3D_acceleration_guide

Down the page there is a test, whohc on my system reports:
glxinfo | grep rendering
direct rendering: Yes
   GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite,
   GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite,
   GL_NV_packed_float_linear, GL_NV_path_rendering,


For me it reads like: Yes, you have hardware accelerated rendering.

Or did I miss something...?
That need not be the whole truth. Look also for ‘OpenGL renderer’ [1] 
with command:

   glxinfo | grep 'render'
or more verbose:
   glxinfo | grep 'string:'

It may be worth to study the Xorg log file for something like:
 - Direct rendering enabled/disabled
 - 2D and 3D acceleration enabled/disabled
 - reverting to software rendering
 - Loaded and initialized swrast (swrast => software rasterizer)
 - and so on ...


References:
[1] 


--
Regards,
floyd

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

[tuxic]

On 04/28 07:32, Fernando Rodriguez wrote:
> On 04/28/2017 02:59 PM, Ian Zimmerman wrote:
> > On 2017-04-28 10:10, Fernando Rodriguez wrote:
> > 
> > > No. I meant you can't enable them *all* globally, meaning opengl,
> > > gles, egl, etc. It's kind of the same situation as with GUI toolkits,
> > > you can't enable them all globally because some packages support more
> > > than one that you have to choose at compile time.
> > 
> > I think we need to spell out what you mean by this:
> > 
> > > > > if any of them have egl or gles and not opengl then enable it.
> > 
> > by "not having opengl" do you mean that it's not in the package's IUSE
> > at all, or that it is disabled?
> 
> On the sentence prior to the one you quoted I advised the OP to enable
> opengl globally. Therefore, if a package has it then it is already enabled.
> So obviously I meant if it doesn't have it at all.
> 
> > by "enable *it*" do you mean enable opengl, or enable those other flags?
> 
> For the same reason stated above I can only be refering to those other
> flags. Those are the flags that control GL acceleration. If you want your
> system to use your GPU as much as possible then you need to enable at least
> one of them on all the packages that support it. If a package has more than
> one it's between you and portage which one you choose because some packages
> depend on one or the other. So I find it easier to enable opengl first and
> then work through the conflicts to enable the others as much as possible.
> 
> -- 
> 
> Fernando Rodriguez
> 

Hi,

before changing my system I took a look at
https://wiki.gentoo.org/wiki/Xorg/Hardware_3D_acceleration_guide

Down the page there is a test, whohc on my system reports:
glxinfo | grep rendering
direct rendering: Yes
GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite, 
GL_NV_path_rendering, GL_NV_pixel_data_range, GL_NV_point_sprite, 
GL_NV_packed_float_linear, GL_NV_path_rendering, 


For me it reads like: Yes, you have hardware accelerated rendering.

Or did I miss something...?

Cheers
Meino

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

[Fernando Rodriguez]

On 04/28/2017 02:59 PM, Ian Zimmerman wrote:

On 2017-04-28 10:10, Fernando Rodriguez wrote:


No. I meant you can't enable them *all* globally, meaning opengl,
gles, egl, etc. It's kind of the same situation as with GUI toolkits,
you can't enable them all globally because some packages support more
than one that you have to choose at compile time.


I think we need to spell out what you mean by this:


if any of them have egl or gles and not opengl then enable it.


by "not having opengl" do you mean that it's not in the package's IUSE
at all, or that it is disabled?


On the sentence prior to the one you quoted I advised the OP to enable 
opengl globally. Therefore, if a package has it then it is already 
enabled. So obviously I meant if it doesn't have it at all.



by "enable *it*" do you mean enable opengl, or enable those other flags?


For the same reason stated above I can only be refering to those other 
flags. Those are the flags that control GL acceleration. If you want 
your system to use your GPU as much as possible then you need to enable 
at least one of them on all the packages that support it. If a package 
has more than one it's between you and portage which one you choose 
because some packages depend on one or the other. So I find it easier to 
enable opengl first and then work through the conflicts to enable the 
others as much as possible.


--

Fernando Rodriguez

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

[Fernando Rodriguez]

On 04/26/2017 03:11 PM, Ian Zimmerman wrote:

On 2017-04-26 12:26, Fernando Rodriguez wrote:


My USE_FLAGS (make.conf) are:



USE="nvidia X lua sdl mp3 flac jack alsa gtk cairo sndfile
qt3support kpathsea gif tga jpeg png jpeg2k mad dvb dvdr encode lzo
bzip2 ogg sox v4l v4l2 vorbis x264 x265 zsh-completion -hal -lirc"



I would start by enabling opengl globally. Then look at the dependency
graph for the packages that you want to accelerate (especially the
toolkits and the whole x11 stack) and if any of them have egl or gles
and not opengl then enable it. You can't enable them all on make.conf
because sometimes they conflict.


Is this advice not in contradiction with itself?  Or what do you mean by
"enabling opengl globally" other than setting a USE flag in make.conf?



No. I meant you can't enable them *all* globally, meaning opengl, gles, 
egl, etc. It's kind of the same situation as with GUI toolkits, you 
can't enable them all globally because some packages support more than 
one that you have to choose at compile time.


--

Fernando Rodriguez

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

[R0b0t1]

On Tue, Apr 25, 2017 at 9:55 PM,   wrote:
> Hi R0b0t1,
>
> On 04/25 02:15, R0b0t1 wrote:
>> On Tue, Apr 25, 2017 at 10:47 AM,   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