1 |
On 04/26/2017 11:27 AM, tuxic@××××××.de wrote: |
2 |
> On 04/26 11:17, Fernando Rodriguez wrote: |
3 |
>> On 04/25/2017 10:38 PM, tuxic@××××××.de wrote: |
4 |
>>> On 04/25 07:38, Floyd Anderson wrote: |
5 |
>>>> On Di, 25 Apr 17:47:22 +0200 |
6 |
>>>> tuxic@××××××.de wrote: |
7 |
>>>>> Hi, |
8 |
>>>>> |
9 |
>>>>> currently I am using urxvt as my standard terminal |
10 |
>>>>> application, which is FAST and reliable. |
11 |
>>>>> But it only emulates 24bit colors if instructed so. |
12 |
>>>>> It maps 24bit rgb to 256 color using a fast but not |
13 |
>>>>> total correct formula to to do (which is no critism - |
14 |
>>>>> its just the way ot is implemented). |
15 |
>>>>> |
16 |
>>>>> I googled qyite a bit to find 24color terminal |
17 |
>>>>> emulators and the one, which came closer to |
18 |
>>>>> what I want is sakure. |
19 |
>>>>> But comparing the speed of sakura with urxvt |
20 |
>>>>> (catting a long log file twice while measureing the time |
21 |
>>>>> of the second cat) it shows that sakura needs |
22 |
>>>>> six times more time than urxvt. |
23 |
>>>>> |
24 |
>>>>> Combining this with the compile sessions, which |
25 |
>>>>> are one of the core features of Gentoo ;)))... |
26 |
>>>>> |
27 |
>>>>> What I want is the "fastest" possible (...) |
28 |
>>>>> terminal emulator supporting true color (24bit). |
29 |
>>>>> I dont need fancy configuring options (two exception: |
30 |
>>>>> TABS! and lightweighted) and I dont want KDE stuff (or |
31 |
>>>>> any other bloated thing with thousands of dependencies...) |
32 |
>>>>> I am simply using openbox. |
33 |
>>>>> |
34 |
>>>>> What are your experiences? |
35 |
>>>>> |
36 |
>>>>> Any hint is heartly welcome! Thanks ! |
37 |
>>>>> |
38 |
>>>>> Cheers |
39 |
>>>>> Meino |
40 |
>>>>> |
41 |
>>>>> PS: The terminal emulator dont need to be part |
42 |
>>>>> of Gentoo necessarily...if it is compilable |
43 |
>>>>> by a human being withoyt super powers... ;) |
44 |
>>>>> |
45 |
>>>> I am using rxvt-unicode also as my main terminal emulator. Its true colour |
46 |
>>>> emulation bothers me also but just only a little bit. |
47 |
>>>> |
48 |
>>>> As a second one, xfce4-terminal runs here from time to time (seldom). A |
49 |
>>>> quick time/cat test with a gcc-5.4.0 log file (approximately 25 MiB) shows |
50 |
>>>> surprisingly that xfce4-terminal runs six time faster than rxvt-unicode. |
51 |
>>>> Maybe one reason is that urxvt looks for URLs and email addresses to |
52 |
>>>> colourising them. |
53 |
>>>> |
54 |
>>>> Maybe you can get a suggestion from [1]. |
55 |
>>>> |
56 |
>>>> |
57 |
>>>> References: |
58 |
>>>> [1] <https://gist.github.com/XVilka/8346728> |
59 |
>>>> |
60 |
>>>> -- |
61 |
>>>> Regards, |
62 |
>>>> floyd |
63 |
>>>> |
64 |
>>>> |
65 |
>>> |
66 |
>>> Hi Floyd, |
67 |
>>> |
68 |
>>> thanks for the informations! :) |
69 |
>>> |
70 |
>>> A few minutes ago I emerged xfce4-terminal and tried the |
71 |
>>> cat-time-test of yesterday: 29 secondes with xfce-terminal |
72 |
>>> and 5 seconds with urxvt. Hmmmm... |
73 |
>>> |
74 |
>>> You have got the reversed results compared with mine... |
75 |
>>> |
76 |
>>> What the heck slows down the output of the terminals on my |
77 |
>>> Gentoo and only let urxvt shine? |
78 |
>> |
79 |
>> Possibly your use flags and/or openbox (if not using a GL compositor). Try |
80 |
>> enabling all GL related flags for the terminal emulator and it's |
81 |
>> dependencies and use a GL compositor like kwin or compiz. Modern graphics |
82 |
>> cards are designed with modern software in mind. Many don't even have a 2D |
83 |
>> engine anymore. |
84 |
>> |
85 |
>> |
86 |
>> |
87 |
>>> |
88 |
>>> Cheers |
89 |
>>> Meino |
90 |
>>> |
91 |
>>> PS: I found XVilka before. That's why I asked for some experiences |
92 |
>>> of other users.... :) |
93 |
>>> |
94 |
>>> |
95 |
>>> |
96 |
>>> |
97 |
>>> |
98 |
>>> |
99 |
>>> |
100 |
>> |
101 |
>> |
102 |
>> -- |
103 |
>> |
104 |
>> Fernando Rodriguez |
105 |
>> |
106 |
> |
107 |
> Hi Fernando, |
108 |
> |
109 |
> thanks for the informations! :) |
110 |
> |
111 |
> I am not using compiz or such.... |
112 |
> |
113 |
> Openbox is installed as follows: |
114 |
> |
115 |
> [I] x11-wm/openbox |
116 |
> Available versions: (3) 3.5.2-r1 (~)3.6 3.6.1 **9999 |
117 |
> {branding debug imlib nls session startup-notification static-libs svg xdg PYTHON_TARGETS="python2_7"} |
118 |
> Installed versions: 3.6.1(3)(11:01:40 AM 02/18/2017)(nls session -branding -debug -imlib -startup-notification -static-libs -svg -xdg PYTHON_TARGETS="python2_7") |
119 |
> Homepage: http://openbox.org/ |
120 |
> Description: A standards compliant, fast, light-weight, extensible window manager |
121 |
> |
122 |
> My USE_FLAGS (make.conf) are: |
123 |
> 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" |
124 |
> |
125 |
> Wpuld you suggest to change a flag? |
126 |
|
127 |
I would start by enabling opengl globally. Then look at the dependency |
128 |
graph for the packages that you want to accelerate (especially the |
129 |
toolkits and the whole x11 stack) and if any of them have egl or gles |
130 |
and not opengl then enable it. You can't enable them all on make.conf |
131 |
because sometimes they conflict. |
132 |
|
133 |
|
134 |
> |
135 |
> Thanks a lot for any help in advance! |
136 |
> |
137 |
> Cheers |
138 |
> Meino |
139 |
|
140 |
|
141 |
-- |
142 |
|
143 |
Fernando Rodriguez |