31 Jul
2004
31 Jul
'04
5:24 p.m.
What do you guys think about this thread?
http://mail.gnome.org/archives/gnome-list/2004-July/thread.html#00071
Am i crazy? Am i the only one who thinks that the current incarnation of
gnome-terminal is slow and a resource hog?
--
Florin Andrei
http://florin.myip.org/
31 Jul
31 Jul
5:41 p.m.
Florin Andrei wrote:
What do you guys think about this thread?
http://mail.gnome.org/archives/gnome-list/2004-July/thread.html#00071
Am i crazy? Am i the only one who thinks that the current incarnation of
gnome-terminal is slow and a resource hog?
No. I recently tried just about every terminal I could get my hands on,
and settled on using aterm like this:
aterm -bg black -fg white +sb -tr -sh 15 -sl 10000 -si -sk -fn 8x13 -ls
-geometry 80x36
and I have room for four of them at once not overlapping. I find that
8x13 and 9x15 are the most readable console fonts. Anti-aliasing just
sucks in a terminal anyway (which is all that aterm cannot do), as much
as I like bitstream vera, and gnome-terminal's scrolling is atrocious
(previous versions don't seem to have this problem). I guess aa is okay
for black text on a white background, but I like a black
semi-transparent background.
Cheers,
Chris
5:49 p.m.
On Sat, 2004-07-31 at 12:30, Chris Pickett wrote:
Florin Andrei wrote:
Nice. But it seems focused on "cute" features such as transparent
background and such.
http://aterm.sourceforge.net/
Are you sure it's the fastest, leanest one?
http://mail.gnome.org/archives/gnome-list/2004-July/thread.html#00071
Am i crazy? Am i the only one who thinks that the current incarnation of
gnome-terminal is slow and a resource hog?
No. I recently tried just about every terminal I could get my hands on,
and settled on using aterm like this:
aterm -bg black -fg white +sb -tr -sh 15 -sl 10000 -si -sk -fn 8x13 -ls
-geometry 80x36 and I have room for four of them at once not
overlapping.
Ahhh... I fondly remember the days when i could do that with
gnome-terminal.
For some obscure reason, no matter how much i tweak it, i can't get it
nowadays to occupy exactly 1/4 of my screen (with two 24 pix control
panels on top and at the bottom of the screen).
--
Florin Andrei
http://florin.myip.org/
6:08 p.m.
Florin Andrei wrote:
On Sat, 2004-07-31 at 12:30, Chris Pickett wrote:
to the point where I would be happy with it forever. I haven't done any
real profiling for memory usage, but like I said, gnome-terminal was
atrocious on my system (750 MHz P3 256 Mb RAM (supposed to be 384 Mb)).
note that i don't like menubars or scrollbars or any of that crap, and
aterm lets you get rid of them easily (scrollbar is shift+pgup/pgdn or
shift+up/dn). usually i just work with 2 or three terminals full
screen, but occasionally unmaximize them. if i remember correctly, it's
like xterm except you can have a transparent background if you want, and
it's a bit lighter too.
just try it ... you can always get rid of it.
cheers,
chris
Florin Andrei wrote:
Nice. But it seems focused on "cute" features such as transparent
background and such.
http://aterm.sourceforge.net/
Are you sure it's the fastest, leanest one?
http://mail.gnome.org/archives/gnome-list/2004-July/thread.html#00071
Am i crazy? Am i the only one who thinks that the current incarnation of
gnome-terminal is slow and a resource hog?
No. I recently tried just about every terminal I could get my hands on,
and settled on using aterm like this:
aterm -bg black -fg white +sb -tr -sh 15 -sl 10000 -si -sk -fn 8x13 -ls
-geometry 80x36
6:24 p.m.
Chris Pickett wrote:
Florin Andrei wrote:
In fact, here. This is four of them side-by-side, with some 80-column
text at 8x13 so you can see the readability (9x15 looks even nicer, and
I would use it if I had a 1600x1200 screen; mine is 1400x1050):
http://www.sable.mcgill.ca/~cpicke/Screenshot-1.png
ps tells me they're each using about 2 Mb of memory.
Cheers,
Chris
On Sat, 2004-07-31 at 12:30, Chris Pickett wrote:
to the point where I would be happy with it forever. I haven't done any
real profiling for memory usage, but like I said, gnome-terminal was
atrocious on my system (750 MHz P3 256 Mb RAM (supposed to be 384 Mb)).
note that i don't like menubars or scrollbars or any of that crap, and
aterm lets you get rid of them easily (scrollbar is shift+pgup/pgdn or
shift+up/dn). usually i just work with 2 or three terminals full
screen, but occasionally unmaximize them. if i remember correctly, it's
like xterm except you can have a transparent background if you want, and
it's a bit lighter too. Florin Andrei wrote:
Nice. But it seems focused on "cute" features such as transparent
background and such.
http://aterm.sourceforge.net/
Are you sure it's the fastest, leanest one?
http://mail.gnome.org/archives/gnome-list/2004-July/thread.html#00071
Am i crazy? Am i the only one who thinks that the current incarnation of
gnome-terminal is slow and a resource hog?
No. I recently tried just about every terminal I could get my hands on,
and settled on using aterm like this:
aterm -bg black -fg white +sb -tr -sh 15 -sl 10000 -si -sk -fn 8x13 -ls
-geometry 80x36 
6:24 p.m.
On Sat, 2004-07-31 at 12:57, Chris Pickett wrote:
note that i don't like menubars or scrollbars or
any of that crap, and
aterm lets you get rid of them easily (scrollbar is shift+pgup/pgdn or
shift+up/dn).
Actually, gnome-terminal is good from a usability p.o.v. I like the way
it has copy/paste keyb shortcuts, i actually use the Reset And Clear
function (makes it easy to copy/paste huge swaths of text), etc.
But, with JACK needing a smooth environment, gnome-terminal seems like a
timed bomb. :-(
usually i just work with 2 or three terminals full
screen, but occasionally unmaximize them. if i remember correctly, it's
like xterm except you can have a transparent background if you want, and
it's a bit lighter too.
Lighter than xterm? I gotta try it!
--
Florin Andrei
http://florin.myip.org/
7:34 p.m.
On Sat, 2004-07-31 at 16:09, Florin Andrei wrote:
On Sat, 2004-07-31 at 12:57, Chris Pickett wrote:
You *have* to use realtime scheduling if you want jackd to work.
Period. Otherwise, the system is doing exactly what you are telling it
to. You have two processes, gnome-terminal and jackd, with the same
priority, so when both of them want to run, it's 50/50 who will get
scheduled. It is *not* gnome-terminal's fault if scrolling text causes
XRUNs in jackd.
If jackd were running SCHED_FIFO aka realtime, and gnome-terminal as a
normal priority process, it would be a bug (priority inversion) if
gnome-terminal *ever* interfered with jackd's operation.
<rant>
BTW it is trivial to demonstrate that gnome-terminal does in fact have
major performance problems. Running 'top' in a maximized gnome-terminal
on a PII-450, the gnome-terminal process takes something like 20% of the
CPU. Just to redraw a screen full of text once per second. When a
program performs *that* much worse than another one for no good reason,
it is called a performance BUG.
I am surprised no one has mentioned the real reason gnome-terminal is
such a CPU hog - font anti-aliasing. The GNOME people say this needs to
be hardware accelerated for decent performance, and that none of the
current video drivers do this. However, Windows does the same thing on
the same machine WAY faster. So either the Linux video drivers are
buggy, or Windows has a 100x faster way to anti-alias fonts.
I think the distros made the wrong choice in putting anti-aliasing into
their desktops before it was ready. I am supposed to be impressed
because the desktop *finally* looks halfway decent compared to Windows,
except *way* slower?
I cannot believe the GNOME developers would respond to the original
complaint with 'hey, don't bug us about performance, we're still adding
FEATURES over here! it's not really a problem, and if it is, you need a
faster machine'. At least *pretend* to be interested in reining in the
bloat.
Can't they understand that I do not want gnome-terminal on my 3Ghz
machine to be about as fast as xterm on a P133? I bought a faster
machine because I want it to do basically the SAME stuff as the old one
but FASTER, and with a few more features! Have you tried a
pre-anti-aliasing distro lately, like RH 7.3? It SMOKES! *Way*
snappier than today's equivalent.
Here is the main point they seem to miss: If I upgrade from a circa
2000 machine (hardware and software) to a 2004, I expect the latter to
be significantly faster *AND* address the limitations of the old
software. In no circumstances should it be slower, or even the same - I
just UPGRADED, remember?
</rant>
Lee
note that i don't like menubars or scrollbars
or any of that crap, and
aterm lets you get rid of them easily (scrollbar is shift+pgup/pgdn or
shift+up/dn).
Actually, gnome-terminal is good from a usability p.o.v. I like the way
it has copy/paste keyb shortcuts, i actually use the Reset And Clear
function (makes it easy to copy/paste huge swaths of text), etc.
But, with JACK needing a smooth environment, gnome-terminal seems like a
timed bomb. :-(
8:01 p.m.
--- Lee Revell <rlrevell(a)joe-job.com> wrote:
I am surprised no one has mentioned the real reason
gnome-terminal is
such a CPU hog - font anti-aliasing. The GNOME people say this needs
to be hardware accelerated for decent performance, and that none of
the current video drivers do this. However, Windows does the same
thing on the same machine WAY faster. So either the Linux video
drivers are buggy, or Windows has a 100x faster way to anti-alias
fonts.
it is slow even with accellerated render extension (tried with xig
radeon drivers, X.org HEAD with Eric Anholt accellerated Render ext for
radeon). I'm using it _without_ AA and it is still much slower then
xterm/aterm/whateverterm.
this helps a little bit:
http://bugzilla.gnome.org/show_bug.cgi?id=143914
--
Fryderyk Dziarmagowski
PLD Linux Distribution
8:56 p.m.
On Sat, 2004-07-31 at 14:19, Lee Revell wrote:
If jackd were running SCHED_FIFO aka realtime, and
gnome-terminal as a
normal priority process, it would be a bug (priority inversion) if
gnome-terminal *ever* interfered with jackd's operation.
Well, i thought Linux can provide only soft realtime, so the
interference is not totally out of question (like it would be on systems
that can do hard or "true" realtime). Am i missing something?
Here is the main point they seem to miss: If I
upgrade from a circa
2000 machine (hardware and software) to a 2004, I expect the latter to
be significantly faster *AND* address the limitations of the old
software. In no circumstances should it be slower, or even the same - I
just UPGRADED, remember?
My point exactly.
--
Florin Andrei
http://florin.myip.org/
10:17 p.m.
On Sat, 2004-07-31 at 18:41, Florin Andrei wrote:
On Sat, 2004-07-31 at 14:19, Lee Revell wrote:
It's not "hard realtime", which is where missing a deadline is
considered a fatal error, and is *never* allowed. The Mars Rovers are a
hard RT - if you are *ever* too late in responding to a 'move wheel'
command, that's it - mission over. It might as well have blown up. A
Cisco BTS (soft switch) is another example. No matter what else the
system is doing, it is not allowed to drop packets under load, or there
would be audible defects. For a cell tower, you could get away with a
soft realtime system, as people *expect* cell phones to suck. OTOH a
BTS has to be every bit as reliable as a hardware phone switch - that
could be someone's 911 call you are dropping, and people expect land
lines to just work, 100% of the time.
In hard-RT systems like this, *every* code path will have been
extensively audited, and tested, then audited some more, until there are
*no* unknowns. In practice, something like a satellite or a Mars rover
is way too complicated to audit every code path with mathematical rigor,
so get it as good as they can, then build in massive redundancy.
Doesn't matter how you achieve it, but the failure rate must be zero.
"Soft realtime", which is what we want, doesn't guarantee that it will
*never* miss a deadline - just that it shouldn't happen too often. BEOS
and IRIX were designed as "soft-realtime" systems, designed in order to
give the lowest possible latency.
Indeed, any time you put a soundcard in a computer you are dealing with
a soft realtime system, because from the time you start capture or
playback audio, you have to get scheduled in time to process the next
block, or you get a gap in the recording. An audible glitch in playback
or recording means the system has failed, just as you would consider the
system to have failed if you copied a file from one disk to another and
it got corrupted. It's actually worse because you cannot go back and
fix the problem. Since any useful system would have to meet these
requirements, "soft realtime" is not used as much - it's just the way
the system is supposed to work.
Generally "realtime" on the linux audio lists refers to soft realtime.
'RT' or 'Hard-RT' means hard realtime.
Lee
If jackd were running SCHED_FIFO aka realtime,
and gnome-terminal as a
normal priority process, it would be a bug (priority inversion) if
gnome-terminal *ever* interfered with jackd's operation.
Well, i thought Linux can provide only soft realtime, so the
interference is not totally out of question (like it would be on systems
that can do hard or "true" realtime). Am i missing something?
1 Aug
1 Aug
2:07 a.m.
On Sat, 2004-07-31 at 17:03, Lee Revell wrote:
On Sat, 2004-07-31 at 18:41, Florin Andrei wrote:
:-D
Dude, i am aware of the difference between soft and hard realtime. I was
merely pointing out that your strong statement ("it would be a bug
(priority inversion) if gnome-terminal *ever* interfered with jackd's
operation") coresponds to the hard realtime situation, while Linux is
(to my best knowledge) soft realtime.
--
Florin Andrei
http://florin.myip.org/
On Sat, 2004-07-31 at 14:19, Lee Revell wrote:
It's not "hard realtime", which is where missing a deadline is
considered a fatal error, and is *never* allowed. The Mars Rovers are a
hard RT - if you are *ever* too late in responding to a 'move wheel'
command, that's it - mission over. If jackd were running SCHED_FIFO aka realtime,
and gnome-terminal as a
normal priority process, it would be a bug (priority inversion) if
gnome-terminal *ever* interfered with jackd's operation.
Well, i thought Linux can provide only soft realtime, so the
interference is not totally out of question (like it would be on systems
that can do hard or "true" realtime). Am i missing something?
5:01 a.m.
On Sat, 2004-07-31 at 23:52, Florin Andrei wrote:
On Sat, 2004-07-31 at 17:03, Lee Revell wrote:
Sorry, that came off totally pedantic, I thought I was replying to the
list vs. email... you would be surprised at how many people *on LKML*
don't understand the distinction.
On Sat, 2004-07-31 at 18:41, Florin Andrei
wrote:
Dude, i am aware of the difference between soft and hard realtime. On Sat, 2004-07-31 at 14:19, Lee Revell wrote:
It's not "hard realtime", which is where missing a deadline is
considered a fatal error, and is *never* allowed. The Mars Rovers are a
hard RT - if you are *ever* too late in responding to a 'move wheel'
command, that's it - mission over. If jackd were running SCHED_FIFO aka realtime,
and gnome-terminal as a
normal priority process, it would be a bug (priority inversion) if
gnome-terminal *ever* interfered with jackd's operation.
Well, i thought Linux can provide only soft realtime, so the
interference is not totally out of question (like it would be on systems
that can do hard or "true" realtime). Am i missing something? I was
merely pointing out that your strong statement ("it would be a bug
(priority inversion) if gnome-terminal *ever* interfered with jackd's
operation") coresponds to the hard realtime situation, while Linux is
(to my best knowledge) soft realtime.
Ok, 'interfere' is too weak. It would be a bug if any normal priority
process caused a SCHED_FIFO process to miss a deadline.
Well, the tricky thing about soft and hard realtime is that they don't
really say anything about the system, but about the guarantees you
willing to make about it, you have to take intent into account. I say
that that is a bug because I think Ingo would consider it one, due to
his definition of how preemption is supposed to work - with the fully
preemptible kernel it is by definition a bug if you have a SCHED_FIFO
process getting blocked by a normal one. This property (no priority
inversions) does not make it hard realtime, because you need to do more
- before redirectable irqs an interrupt handler would preempt any
process any time an interrupt occurred, potentially causing your
SCHED_FIFO process to get blocked and miss a deadline. So preventing
priority inversion is one half of the problem, you also need a way to
keep interrupts from blocking your process, or vice versa, if you want
to make a real time guarantee about interrupt response times. Those two
ingredients (actually three because the scheduler becomes increasingly
important once irqs are threaded) are the building blocks for hard-RT,
which is what I think Ingo means about the latest changes making the
kernel hard-RT capable.
Lee
12:27 a.m.
On Saturday 31 July 2004 05:19 pm, Lee Revell wrote:
On Sat, 2004-07-31 at 16:09, Florin Andrei wrote:
Oh man... B-b-b-b-b-ut they just eliminated features!
On Sat, 2004-07-31 at 12:57, Chris Pickett
wrote:
You *have* to use realtime scheduling if you want jackd to work.
Period. Otherwise, the system is doing exactly what you are telling it
to. You have two processes, gnome-terminal and jackd, with the same
priority, so when both of them want to run, it's 50/50 who will get
scheduled. It is *not* gnome-terminal's fault if scrolling text causes
XRUNs in jackd.
If jackd were running SCHED_FIFO aka realtime, and gnome-terminal as a
normal priority process, it would be a bug (priority inversion) if
gnome-terminal *ever* interfered with jackd's operation.
<rant>
BTW it is trivial to demonstrate that gnome-terminal does in fact have
major performance problems. Running 'top' in a maximized gnome-terminal
on a PII-450, the gnome-terminal process takes something like 20% of the
CPU. Just to redraw a screen full of text once per second. When a
program performs *that* much worse than another one for no good reason,
it is called a performance BUG.
I am surprised no one has mentioned the real reason gnome-terminal is
such a CPU hog - font anti-aliasing. The GNOME people say this needs to
be hardware accelerated for decent performance, and that none of the
current video drivers do this. However, Windows does the same thing on
the same machine WAY faster. So either the Linux video drivers are
buggy, or Windows has a 100x faster way to anti-alias fonts.
I think the distros made the wrong choice in putting anti-aliasing into
their desktops before it was ready. I am supposed to be impressed
because the desktop *finally* looks halfway decent compared to Windows,
except *way* slower?
I cannot believe the GNOME developers would respond to the original
complaint with 'hey, don't bug us about performance, we're still adding
FEATURES over here! it's not really a problem, and if it is, you need a
faster machine'. At least *pretend* to be interested in reining in the
bloat.
note that i don't like menubars or scrollbars
or any of that crap, and
aterm lets you get rid of them easily (scrollbar is shift+pgup/pgdn or
shift+up/dn).
Actually, gnome-terminal is good from a usability p.o.v. I like the way
it has copy/paste keyb shortcuts, i actually use the Reset And Clear
function (makes it easy to copy/paste huge swaths of text), etc.
But, with JACK needing a smooth environment, gnome-terminal seems like a
timed bomb. :-( Can't they understand that I do not want
gnome-terminal on my 3Ghz
machine to be about as fast as xterm on a P133? I bought a faster
machine because I want it to do basically the SAME stuff as the old one
but FASTER, and with a few more features! Have you tried a
pre-anti-aliasing distro lately, like RH 7.3? It SMOKES! *Way*
snappier than today's equivalent.
This list isn't the place for it, but... If I was a ranking gnome developer...
and I was employed by XYZ... Which happens to be a big company with a vested
interest in gnome/linux... I might make some decisions that... were in tune
with company policy.. Not because it was my job.... but I'd still have office
politics to contend with because I'd want to keep said job.
One has to acknowledge at least the possibility of that sort of thing
affecting ones evaluation of the world. They are only human. The attitudes at
the top filter down to everybody else.
Whatever works is my credo.
Here is the main point they seem to miss: If I
upgrade from a circa
2000 machine (hardware and software) to a 2004, I expect the latter to
be significantly faster *AND* address the limitations of the old
software. In no circumstances should it be slower, or even the same - I
just UPGRADED, remember?
</rant>
Lee
1:17 a.m.
On Sat, 2004-07-31 at 22:21, John Check wrote:
Yeah, I understand that in the real world no one likes to pay
programmers to make things faster. "Well, yeah, it's faster, I could
get the same result by just throwing more hardware at it, and it's
cheaper than paying you coders". From reading the Fedora lists the Red
Hat people were a lot more worried about adding internationalization
support or whatever than about making it faster - at some point I think
they just decided to hell with performance. Which makes perfect sense,
when you consider that the slowness is the least of your worries if the
thing does not even speak your language yet.
I do understand Red Hat's motivations - I have to admit I was pretty
impressed at how good FC1 looked the first time I saw it, so much so
that it took me a while to realize how much performance they had to give
up. That was the first Linux distro that made me thing 'this could
replace windows for 99% of what people do'. Correctly designed software
will always be significantly slower than the equivalent hack job
(Windows).
Plus you can always count on the speed demons out there fixing
performance problems in your code. If you wait around for them to
translate it into Urdu... not the greatest business model.
That being said, it kind of looks like they might have papered over the
problem, by increasing the block size and making it consistently
slow-ish. However it takes the exact same amount of time to do the seq
test every time. xterm, uxterm, rxvt, urxvt all are very choppy - if
you run the seq test 10 times, it will be blazingly fast a few times (1
sec), but it's usually more like 9-10 secs. Also, it seems like it's
slow until the first line of your output reaches the the top of the
screen, then the rest is very fast. None of these are nearly as bad as
gnome-terminal used to be.
Lee
On Saturday 31 July 2004 05:19 pm, Lee Revell wrote:
Really? Haven't missed them yet...
On Sat, 2004-07-31 at 16:09, Florin Andrei
wrote:
Oh man... B-b-b-b-b-ut they just eliminated features! On Sat, 2004-07-31 at 12:57, Chris Pickett wrote:
I cannot believe the GNOME developers would respond to the original
complaint with 'hey, don't bug us about performance, we're still adding
FEATURES over here! it's not really a problem, and if it is, you need a
faster machine'. At least *pretend* to be interested in reining in the
bloat.
Can't they understand that I do not want
gnome-terminal on my 3Ghz
machine to be about as fast as xterm on a P133? I bought a faster
machine because I want it to do basically the SAME stuff as the old one
but FASTER, and with a few more features! Have you tried a
pre-anti-aliasing distro lately, like RH 7.3? It SMOKES! *Way*
snappier than today's equivalent.
This list isn't the place for it, but... If I was a ranking gnome developer...
and I was employed by XYZ... Which happens to be a big company with a vested
interest in gnome/linux... I might make some decisions that... were in tune
with company policy.. Not because it was my job.... but I'd still have office
politics to contend with because I'd want to keep said job.
One has to acknowledge at least the possibility of that sort of thing
affecting ones evaluation of the world. They are only human. The attitudes at
the top filter down to everybody else.
1:34 a.m.
Lee Revell wrote:
I do understand Red Hat's motivations - I have to
admit I was pretty
impressed at how good FC1 looked the first time I saw it, so much so
that it took me a while to realize how much performance they had to give
up. That was the first Linux distro that made me thing 'this could
replace windows for 99% of what people do'. Correctly designed software
will always be significantly slower than the equivalent hack job
(Windows).
I beg to differ. A good design lets you replace inefficient algorithms
and components quickly and cleanly after profiling.
Chris
9:34 p.m.
On Sat, 2004-07-31 at 14:19, Lee Revell wrote:
On Sat, 2004-07-31 at 16:09, Florin Andrei wrote:
I did run into the gnome terminal slowness when doing some jack tests
under 2.6.x + FC2. I think the problem _may_ be inside jack. Some error
reporting functions use just a printf from inside a realtime thread. So,
an error occurs (xrun, for example), jack prints it out, gnome-terminal
is really slow, which causes another error (the printf and everything it
calls is running realtime, right?), which is printed by jack and so on
and so forth (or at least I think that is what is happening). The whole
machine slows down to a crawl. Running jack from an xterm significantly
changes the behavior for the better. And yes, it is the fault of
(mainly) antialiasing, turning it off makes the fonts really ugly but
performance is back to something halfway decent.
I noticed because I was looking at the cpu meter applet and saw big
spikes that where happening at the same time as the terminal scrolls!
-- Fernando
On Sat, 2004-07-31 at 12:57, Chris Pickett
wrote:
You *have* to use realtime scheduling if you want jackd to work.
Period. Otherwise, the system is doing exactly what you are telling it
to. You have two processes, gnome-terminal and jackd, with the same
priority, so when both of them want to run, it's 50/50 who will get
scheduled. It is *not* gnome-terminal's fault if scrolling text causes
XRUNs in jackd. note that i don't like menubars or scrollbars
or any of that crap, and
aterm lets you get rid of them easily (scrollbar is shift+pgup/pgdn or
shift+up/dn).
Actually, gnome-terminal is good from a usability p.o.v. I like the way
it has copy/paste keyb shortcuts, i actually use the Reset And Clear
function (makes it easy to copy/paste huge swaths of text), etc.
But, with JACK needing a smooth environment, gnome-terminal seems like a
timed bomb. :-(
10:20 p.m.
On Sun, 2004-08-01 at 19:19, Fernando Pablo Lopez-Lezcano wrote:
So,
an error occurs (xrun, for example), jack prints it out,gnome-terminal
is really slow, which causes another error (the printf and everything it
calls is running realtime, right?), which is printed by jack and so on
and so forth (or at least I think that is what is happening). The whole
machine slows down to a crawl. Running jack from an xterm significantly
changes the behavior for the better. And yes, it is the fault of
(mainly) antialiasing, turning it off makes the fonts really ugly but
performance is back to something halfway decent.
I noticed because I was looking at the cpu meter applet and saw big
spikes that where happening at the same time as the terminal scrolls!
What video hardware and motherboard are you using?
Does the problem go away if you set Option "NoAccel" in the "Device"
section of XF86Config?
Lee
10:48 p.m.
On Sun, 2004-08-01 at 17:06, Lee Revell wrote:
On Sun, 2004-08-01 at 19:19, Fernando Pablo
Lopez-Lezcano wrote:
This was on a laptop, p4 1.7Ghz, 512M ram, radeon video chipset, dri
enabled. The kernel I was running was patched with the "illegal" drm low
latency patch (which does a reschedule with a lock held but gets rid of
10/15msec scheduling delays - I know, bad boy, no cookie :-).
So,
an error occurs (xrun, for example), jack prints it out,gnome-terminal
is really slow, which causes another error (the printf and everything it
calls is running realtime, right?), which is printed by jack and so on
and so forth (or at least I think that is what is happening). The whole
machine slows down to a crawl. Running jack from an xterm significantly
changes the behavior for the better. And yes, it is the fault of
(mainly) antialiasing, turning it off makes the fonts really ugly but
performance is back to something halfway decent.
I noticed because I was looking at the cpu meter applet and saw big
spikes that where happening at the same time as the terminal scrolls!
What video hardware and motherboard are you using? Does the problem go away if you set Option
"NoAccel" in the "Device"
section of XF86Config?
I don't know, I will retest when I have a chance. This is further
complicated with the problems jack has with 2.6.x/nptl.
If I find a moment I would like to catch up to the latest patches and
get a newer 2.6.x running before retesting. I've been on a trip and then
busy with a big move and have been trying to keep with the latest (and
salivating over the latencies reported on 2.6.x)...
-- Fernando
31 Jul
31 Jul
7:38 p.m.
New subject: [linux-audio-user] (OT) gnome-terminal performance
>usually i just work with 2 or three terminals full
>screen, but occasionally unmaximize them.
Does it have a "tab" type of thing. You know... one window with the
ablility to click to different occurances. It's getting to the point
were just about everything that I use has tabs... Netscape, "Console"
(KDE X terminal). Even Konqueror (KDE's File-Manager/Web-Browser) has tabs.
...One window for each program and an uncluttered system tray.
Rocco
1 Aug
1 Aug
12:18 a.m.
New subject: [linux-audio-user] (OT) gnome-terminal performance
LinuxMedia wrote:
I do like this about programs, but aterm doesn't have it. It isn't
really a GUI application at all (which is why I love it, really). When
I was using fluxbox, it had the ability to tab applications at the
window manager level, and I thought that was really neat. Now I'm using
GNOME 2.6, and it doesn't have it, but it's no big deal to me.
Chris
>usually i
just work with 2 or three terminals full
>screen, but occasionally unmaximize them.
Does it have a "tab" type of thing. You know... one window with the
ablility to click to different occurances. It's getting to the point
were just about everything that I use has tabs... Netscape, "Console"
(KDE X terminal). Even Konqueror (KDE's File-Manager/Web-Browser) has tabs.
...One window for each program and an uncluttered system tray. 
3 Aug
3 Aug
12:56 p.m.
New subject: [linux-audio-user] (OT) gnome-terminal performance
On Sat, 31 Jul 2004 16:21:14 +0000
LinuxMedia <linuxmedia4(a)netscape.net> wrote:
Multi-aterm is based on aterm sources and should do just what you want.
http://www.nongnu.org/materm/materm.html
>usually i
just work with 2 or three terminals full
>screen, but occasionally unmaximize them.
Does it have a "tab" type of thing. You know... one window with the
ablility to click to different occurances. It's getting to the point
were just about everything that I use has tabs... Netscape, "Console"
(KDE X terminal). Even Konqueror (KDE's File-Manager/Web-Browser) has
tabs. ...One window for each program and an uncluttered
system tray.
Rocco
31 Jul
31 Jul
6:22 p.m.
Florin Andrei wrote:
What do you guys think about this thread?
http://mail.gnome.org/archives/gnome-list/2004-July/thread.html#00071
Am i crazy? Am i the only one who thinks that the current incarnation of
gnome-terminal is slow and a resource hog?
No, you're not. It is very slow.
-- Brett
1 Aug
1 Aug
4:28 a.m.
On Sat, Jul 31, 2004 at 12:08:48PM -0700, Florin Andrei wrote:
What do you guys think about this thread?
http://mail.gnome.org/archives/gnome-list/2004-July/thread.html#00071
Am i crazy? Am i the only one who thinks that the current incarnation of
gnome-terminal is slow and a resource hog?
All the result of going to unicode for the default locale. A well-known
limitation.
--
Jack Bowling
mailto: jbinpg(a)shaw.ca
7206
days inactive
7209
days old
linux-audio-user@lists.linuxaudio.org
22 comments
10 participants
participants (10)
-
caffeine -
Chris Pickett -
Fernando Pablo Lopez-Lezcano -
Florin Andrei -
Fryderyk Dziarmagowski -
Jack Bowling -
John Check -
Lee Revell -
LinuxMedia -
Them