One thing to note here is that all terminals are sharing the same process...

That said, it is true that we need to work on speed. Help with profiling vte
would be very appreciated...

Created attachment 26446 [details]
a profile of a minimized gnome-terminal scrolling lots of text

Here's a profile for you!

To generate this profile, I just ran hexdump -C <large AVI movie file> inside a
gnome-terminal, which I immediately minimized (i.e. for 99.9% of the time, there
was no window at all, just an entry in the gnome panel). 

The highlights seem to be: 

_vte_table_match (10% of total time)
_vte_draw_set_scroll (5%)
_vte_buffer_length (3%)
gdk_pixbuf_scale (15%)
pixops_scale (7%)
g_array_append_vals (4%)
g_tree_search (8%)


    I'm just guessing here, but looking at some of these names, perhaps it's
time to get the hash table shotgun out 8)

Created attachment 26447 [details]
a profile of a visible gnome-terminal scrolling lots of text

OK, here's another profile: the same test (long hexdump (several minutes), ^C,
exit), but this time with the gnome-terminal visible (80x25, no huge fonts or
anything).

Interestingly, _vte_table_match remains at 10%, g_array_append_vals is still 4%
and g_tree_search is still 8% but there are some new heavy hitters:

_vte_draw_fill_rectangle (5%)
_vte_buffer_clear (3%)
gdk_pixbuf_new_from_data (22% !)

One thing I noticed upon starting the hexdump is that for a few thousand lines
it seemed to run very quickly, but after that it slowed down to something like a
90% duty cycle, i.e. 10% of the time the terminal would just sit there, not
scrolling. About once a second or so, these 0.1s pauses would show up, but only
after a few thousand lines had scrolled past smoothly. I'm guessing this is the
terminal log buffer filling up, and gnome-terminal deciding to do some house
cleaning every once in a while...

could someone tell me how to profile gnome-terminal?

i got gnome-term and vte from gnome.org

compiled them with -pg, but still.. in the profiler output every
function is listed with 0% :(((

Try qprof from HP: http://www.hpl.hp.com/research/linux/qprof/

It's designed for Itanium systems but I think you can get the basic
functionality on other platforms too.

OK, I just performed a quick benchmark between gnome-terminal and rxvt-unicode
with the same font (10 point lucida console, antialiased (not subpixel
rendered)), running hexdump -C <1.7 megabyte file> in an 80x25 window.

rxvt-unicode:   17.90 seconds (baseline)
gnome-terminal: 71.11 seconds (4 times slower)


For the same test, but with a maximized (1600x1200 display) terminal window:

rxvt-unicode:    18.47 seconds (3.2% slower)
gnome-terminal: 288.06 seconds (**16 TIMES** slower (!))

Note: The same amount of text is being rendered in each case, and it's being
rendered the same way. The same amount of scrollback is being used in each case.
These terminals are basically doing the same thing. About the only visible
difference is that the gnome-terminal scrollbar has a "jellybean" widget whereas
rxvt has a simpler 2D scrollbar. (We're not completely redrawing the scrollbar
once per line scroll, are we?)

Another test: running the same hexdump test, but in a minimized (completely
invisible) terminal window:

rxvt-unicode:    2.891 seconds
gnome-terminal: 29.212 seconds

And now, for the "what the hell is going on here" factor: the previous two
figures were for terminal windows that were 80x25 characters in size before
being minimized (simply did a sleep 10; hexdump ... )

Maximizing the terminals (1600x1200 pixels) before minimizing them, the
rxvt-unicode time is unchanged but the gnome-terminal time is:

228.69 seconds. Not a bad effort for what should be effectively copying 10 or
20MB of data into a buffer.

Changing severity from "enhancement" to "normal" because while this is a
performance issue, something is going seriously wrong here.
 

Moving this to vte: mariano assures me that the problem is there.

Upgrading to major: the first person to fix this (fix = performance is within a
factor of 2 of rxvt-unicode for all four of the tests here) gets $50 from me, or
an expensive dinner + all the beer they can handle if they ever visit Sydney,
Australia ;)

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=83472 might also have some
relevant information...

Moving from the "grand canyon" theme to the "simple" one:

gnome-terminal: 71.11 seconds (4 times slower)

becomes 47.35 seconds

and when minimized,

gnome-terminal: 29.212 seconds

becomes 15.997 seconds

still terribly slow, but it's a start. _why_ are we even redrawing the scrollbar
when it is exactly the same 99.99% of the time?

(and once again, what the heck does the theme have to do with an invisible window?)

interestingly, for the maximized window, the test ran slightly slower (about 2%)
with the simple GTK theme. within experimental error, I guess.

OK, attaching a profile for a basic, visible (80x25 chars) terminal scrolling
hexdump -C <1.7MB bloat>, with a simple GTK theme.

Created attachment 27332 [details]
a profile of a visible gnome-terminal scrolling text - simple GTK theme

Created attachment 27334 [details]
profile of 1600x1200 gnome-terminal scrolling tons of text, simple GTK theme

and here's the same test as the previous profile, but this time the window is
1600x1200 pixels in size

Nalin, sorry to drop this one on you without warning: I shouldn't have left this
sitting as a gnome-terminal bug for so long.

*** Bug 131461 has been marked as a duplicate of this bug. ***

Bug 131461, which I just marked as a dup, has some timings for the usual things
(ls -lR, print a few thousand lines of something, etc) of varying significance...

hmm... could the reporter add some info about his hardware?

what graphics card?
what driver for his graphics card ( a binary driver from the card-manufacturer?
or the driver from xfree?)
what version of xfree?

Sure, no problem.

Graphics card: NVidia Quadro4 980 XGL
Driver: NVidia 53.36 and 53.47 binary drivers
XFree: tested both 4.3.0.1 (Debian 4.3.0.dfsg.1-1 20040428210751) and 4.4.0-ish
CVS (built by hand)

I would be very, very surprised if the hardware or video driver have anything to
do with this: remember, rxvt and other GTK+ programs (such as gvim) all scroll
text far, far more rapidly than gnome-terminal.

please read bug 131461 ..my comments to be exact...

so..could you try to switch to the xfree nvidia driver... (replace "nvidia" with
"nv" in XF86Config)

OK, I just tried the xfree nv driver. Exactly the same behaviour, except that
characters come up more slowly so instead of using closer to 2 CPUs worth of
time (I have a 2-way SMP box), it's somewhat closer to 1.0 (XFree86 hits 100% as
before, but with the xfree driver hexdump/gnome-terminal don't use as much time
as they're waiting for a much slower xfree display...)

This bug really doesn't have much to do with XFree itself: there is no good
reason that XFree86 should be doing _anything_ significant while stuff is
happening inside a _completely invisible_ gnome-terminal window. Needless to
say, the minimized gnome-terminal continues to soak up massive amounts of CPU
time while a multi-megabyte hexdump inside rxvt runs about 20 times faster.

*** Bug 143345 has been marked as a duplicate of this bug. ***

*** Bug 144085 has been marked as a duplicate of this bug. ***

Tagging this critical+urgent. How dare I, you ask? Doubling the reward - $100 if
this is fixed (see above) before September 1, 2004. $0 after that (and I'll
return it to a normal bug ;) If anyone else wants to contribute to whoever ends
up fixing this, please join in..

btw. maybe u will hate me for this.....

but imho many people who have problems with gnome-term will find this bug, and i
don't want them to switch to kde (btw. which has a PERFECT console app),

here's a small list about what can u use until this gets fixed:
mlterm: does utf8 + transparency + especially optimised for asian fonts/input
(every transparent mlterm uses a copy of the wallpaper. they don't share that
between their instances like gnome-term does)

rxvt-unicde (i use this one): does utf8 + transparency (no sharing of the
wallpaper between instances). no menu... for the beginning try this command-line:

urxvt -ip -fg white -bg black -fn "xft:Bitstream Vera Sans Mono" -tint
-rgb:30/30/30 -sr -sl 1024 -colorBD white

Me and friend of mine are sick and tired of this bug (it's haunting us from
gnome 2.0) so we are decided to do something about it! Until 1 Sep 2004 the bug
will be gone! :)

Great, good luck! If you send patches here, I'll do my best to try and update
the profile information.

Hi, I am the author of rxvt-unicode, and have some comments.

First of all @Gabor Farkas: of course rxvt-unicode has a menu. There is no
excuse for people sprreading FUD that could easily be clarified by reading rthe
manual page *g*.

Xft fonts are slow, but that is not the problem of gnome-terminal, as xterm
(Also slow) and rxvt-unicode (much slower than non-xft) are much afster. So much
is already clear from reading this bug-report.

gnome-terminal uses pango, and I hear that this is required for correct i18n. I
just installed gnome-terminal 2.6.1-4 (debian), and found that, while
gnome-terminal uses pango, the font drawing is much worse than rxvt-unicode:
arabic is broken, characters run into each other.

Pango is *extremely* slow (orders of magnitude slower than using x core fonts or
even directly using xft fonts), but what you get from using pango is correct
rendeing of realyl complex scripts (arabic for example). In gnome-terminal, it
seems as if pango slows down gnome-terminal with no additional benefit.

Redrawing the scrollbar should not be a bottleneck in gnome-temrinal, as rxvt
redraws the scrollbar completely, unptimised, on every scroll.

Also, using blitting on scrolls and waiting for expose events (as suggested) is
slowing down redrawing immensely, and is only of help on slow links (blitz ==
less data over the link).

In almost all cases it is much faster to just re-draw the screen on changes.
Don'T create expose events by using any kind of optimized scroll, that might be
a bit better for cpu time, but slows down redrawing because it needs
server-turnarounds.

For example, strace rxvt and gnome-terminal: when scorlling, rxvt does not read
from the server, it just sends data to the server: no server timearound. (the
effect can bets be seen if you emnable blinking and use blinking tetx. usually
rxvt-unicode's strace will look like
select/timeout/gettimeofday/write/write/select/timeout etc.

Also, double-buffering is very slow. Try turning of double-buffering in the
display widget. If it now flickers, you have a problem. xterm flickers a lot on
redraws, rxvt less and rxvt-unicode almost none as it draws the background while
redraing characters (useing XDrawImageString if possible, or clearing just
before drawing in other cases).

I just improved rxvt-unicode's scrolling speed a lot, and I am seeing similar
problems to xterm and gnome-terminal which I tried to solve. First of all, a
major point of slowdown (ignoring actual drawing of the characters) is not doing
jump-scrolling. I am not sure wether gnome-terminal does jump-scroling, it
doesn't look that way to me.

Some terminals (eterm for example) cheat a lot by only showing 1/5th of the
text, i.e. only drawing every firth full-screen when scorling hard. rxvt-unicode
also dowsa this, but only for every second screen. You can edit command.h
REFRESH_PERIODS to adjuts this value for tests. I think xterm cheats even more,
but I think it's important to show almost all the text, so I don't think
omitting output excessively is a good idea.

A common problem (as testified in other gnome-terminal bug-reports) is scheduler
interaction. The original rxvt dfoes not realyl suffer from this, as it uses a
tight inenr loop, while rxvt-unicode and gnome-temrinal use an event system,
which makes these things mroe difficult (Difefrent priorities for different file
handles for example).

Terminal output is often line-by-line: redrawing after eahc tty-read is
therefore going to be dog-slow. Newer linux kernels can buffer up to 4095 (sic!)
characters, but that's not universal, and might help terminals.

rxvt-unicode has two modes of scrolling: normal mode, where refreshes are
delayed by 0.01 seconds (i.e. it will only update the screen 0.01s aftere the
last change, wqhich is always early enough), and hard-scrolling, which is
triggered automatically when there is more output than fits on one screen.

The latter ensures that redraws are done more often when lots of tetx scrolls
by. Also, only showing every second screen is only done when the amount of data
overwhelms rxvt, on normal output (typicall ls output) it will still show every
screen.

In any case, redrawing immediately after receiving data is a no-no.

Also, resources: urxvtd with 10 open terminals (no scrolling done yet) uses 6MB
of memory (2MB rss), while a single gnome-terminal already uses 40MB memory
(15MB RSS). cpu caching is a major concern in modern machins, and it's possible
that the sheer amountof code run in gnome-terminal causes a lot of cache-misses
that smaller terminals don't have. This does not apply to konsole as much, which
is also big (but way smaller than gnome-terminal still :)

Last not leats: the scrollback buffer. I use large scrollback buffer s(many
thousands of lines). original rxvt uses a for-loop to shuffle the line pointers
around in memory. replacing that by a memmove gave me (GNU/Linux-x86) a 5%
increase in scrolling speed. I wil be able to reduce this further.

Other data structures (lists etc.) are bound to be slower, though, due to
cache-effects and the sheer slowness of acecssing them.

Please note that rxvt-unicode also uses jump-scrolling _internally_, i.e. it can
add a screenful of lines without doing any scorlling internally). As copying
characters from the tty to internal buffers is using a non-trivial amount of
time (using mbtowc is already a major-time-burner!) this saves a LOT of time.

... I think I forgot a few minor points, but the above might be helpful for
anybody trying to improve gnome-terminal... I must honestly admit that
gnome-terminal really *is* slow, even for it's features... :)

Sorry fot the additional comment, and sorry for the many typoes (a textarea is
not a nice place to edit large amounts of text :).

I just did some experiments with konsole, which seems to ahve become very much
faster (it's almost as fats as rxvt-unicode, sometiems even fatser). However, I
noticed that it only redraws the screen about 7 times per second (see the
section about terminals cheating in my last comment). When this is switched off,
konsole isn't that much faster anymore than gnome-terminal.

I am thinking about making this a prefernces option in rxvt-unicode: some people
don't really want all tetx on screen screen, others (like me) want that,a s
analysing afst output streams (e.g. tcpdump) is still possible even when youc
an'T read the text scrolling by (the human visual system is amazing :).

Aggressively mitigating and delaying scrolls by 0.1s or more might be a major
speed increase, at least profilign data suddenly becomes more valid. If this is
a prefernces item than most of the problems (related to redraw time, there might
be others) are gone, at the same cost as konsole, and I don't see many peopel
complaining.

Created attachment 30710 [details] [review]
walk the string ourselves instead of using memchr 6+ times

First optimization:
There's a function that tries to find the first control character in a string.
The current code walks that string using memchr for every control character
resulting in 6+ iterations over the string.
This patch optimizes it and walks the string only once.

Benjamin: Note that your patch is already included as part of the patch in bug
143914 (submitted a couple months ago).  Also note that there are various
patches in bug 122656 (some up to a year old, although some may be solaris
specific).  You may want to read those patches before continuing.

Created attachment 30714 [details] [review]
use a custom GTree in the xfs backend

This is a minor optimization that creates a custom GTree type that optimizes
ASCII character lookups by having the first n values cached in an array instead
of adding them to the tree.

Created attachment 30715 [details] [review]
Don't use a GArray, use a calloc'ed mem

vte_terminal_draw_row allocates a GArray every time it is called to assemble
the drawing requests. This causes a lot of (re)allocations. This patch changes
it to use alloca with the maximum number of requests (column width, or can
there be more?) instead.

Created attachment 30723 [details] [review]
Don't update the slider when the slider didn't change

This patch is a bit intrusive and might have side effects I didn't find yet.
But it improves speed a lot.

VTE has a GtkAdjustment that's used by the slider in gnome-terminal. Currently
the adjustment's values are absolute, that means the maximum value is the
number of lines ever added inside the terminal. So when you add a new line to
the terminal (by pressing return for example), the last line from the history
gets deleted, but  the asjustment gets updated: Upper bound, lower bound and
current value all get incremented by one. This causes gnome-terminal to update
the slider.

This patch makes the adjustment always number the oldest line in the history -
and therefore the lower bound of the adjustment - as 0. The upper bound is
therefore only limited by the visible area and the number of scrollback lines
and doesn't get changed when lines get inserted.

This results in the slider not being updated. 

hexdumping or cat'ing a big file is up to 50% faster with this patch.

Elijah: yeah, someone should apply those patches at some point or assemble all
performance improvements in one bug report it seems :)

The last 3 patches are new though. And the first one was obvious anyway. ;)

FWIW, with all these patches applied cat'ing a ~1MB file in a fullscreen
terminal (150x40 I think) now takes 14 instead of 43 seconds, in a 80x25
terminal it takes 7 instead of 23 seconds.

Created attachment 30798 [details] [review]
second try with not updating the slider

The last patch was quite a bit broken, this one is supposed to be better.

Thanks for that - I had tried your previous patch set, but the scrolling was
indeed very broken. I'll try again soon (sometime today), and get back with
performance figures.

Benjamin, bad news :(  Here are my timings:

baseline (gnome-terminal 2.7.3, vte 0.11.11): 65 (+/-5) seconds (some fixed
hexdump output)

applying only the slider patch: 80 seconds

applying all the patches except the custom GTree: 74 seconds

applying all the patches: 77 seconds

So I wonder, what is your system like? Which theme are you using? What does
'x11perf -aaftext' report for your system? (I get 1,230,000 chars/sec, or in
other words, just drawing the glyphs for this test should take around 7.5 seconds)

Duraid: Could you post what timings you obtain with the patches in bug 143914
and maybe also bug 122656?

OK, I just tested the patch in bug 143914. This patch seems to be a win. In an
attempt to get something like a fair comparison, I altered VTE_COALESCE_TIMEOUT
and VTE_DISPLAY_TIMEOUT to both be 2.

The benchmark then completed in 51.8 seconds, not 65 as before. Nevertheless, it
did still seem as if less text was being rendered but that could just be my
memory playing tricks on me. It's also worth bearing in mind that the "optimal"
time for this test (i.e. if gnome-terminal and vte both use zero CPU time) is
still around 10 seconds, not zero. So the improvement is significant: a 25%
boost or so.

However, the real win comes when setting VTE_COALESCE_TIMEOUT and
VTE_DISPLAY_TIMEOUT to larger values. e.g. using values of 3 and 5 respectively,
the benchmark finishes in 23 seconds, but appears to be scrolling at the same
rate as with 2/2. Nevertheless, there are still usability issues, even with
these small values. If I maximize gnome-terminal and 'ls -la' my messy home
directory (around 1000 files+), it finishes quickly enough but the variance in
what I see between runs is huge, and if it wasn't for the fact that I already
know what's in there, I wouldn't be able to tell much. The text moves slowly
enough that it's easily readable and I think a user will get the illusion that
he has seen enough, when he actually hasn't - the majority of the text is simply
never drawn. With rxvt-unicode on the other hand, the text scrolls SO fast that
at least the user makes the correct judgement: he didn't catch the output, and
must use a pager or something.

For the record, with Soren's patch as-is, the benchmark finishes in under 20
seconds but the amount of text output is pitifully small. This, as far as I'm
aware, is changing gnome-terminal in the same way KDE's terminal has changed
recently (boost speed by massively reducing the amount of text output) and I
really feel that's the wrong direction to be going in.

I might have been using a slightly more demanding theme and since the slider is
repainted immediately after changes, it might have been more visible for me.
(I'm using the aquativo theme.)

I'll just attach all my changes I've currently done in a big cumulative patch
when I'm back on my machine.

We should also try to use roughly the same benchmark, so we know what we are
talking about. I'm using time gnome-terminal --disable-factory -x <command>
where command is one of {cat|hexdump} {configure|src/vte.c} for the default test
or I run time <command> in a maximized window (40x150).

here are some times that I came up with: My X server is on a machine on the LAN
but terminals are run on my local machine. All terminals use same AA font, same
size window(80x40), and transparency where available(urxvt, g-t). This is on
solaris.

this was run repeatedly in all terminals to avoid I/O caching unfairness to the
first runner.

time /bin/ls -R /usr/share

urxvt: 36 secs
xterm: 15 secs
g-t: 6 secs

network usage:
urxvt: < 1M
xterm: 5-6M
g-t: 4-5M

urxvt slows down a lot because it talks to X server in smaller chunk sizes as is
evident from the network usage shown by gkrellm. Even locally on my gentoo box,
my results show it to be slower(please don't flame me, because I am the only one
saying this) than g-t and xterm....g-t has patches applied only from bug 122656.
vte has URL highlight turned off as described in 122656. The URL highlight was
the biggest slow down and removing which made it faster than everything else.

It might be worthwhile to comment out #define NO_SLOW_LINK_SUPPORT in
src/features.h of urxvt to get a more comparable benchmark for this case, as by
default urxvt will try to save bandwidth by using xcopyarea when run without a
local display (the effetc of which cna be seen by the amount of data transferred).

XCopyArea can slow down scorlling a lot, due to the high number of event
turnarounds that this generates, but it is rather effective when using a
terminal emulator over  aslow line.

If you wanted to do the urxvt author a favour you could also try without
transparency and with the most current version (3.7+), as urxvt's wekanesses
include transparency,a nd it would be nice to find out why urxvt suddenly became
so slow compared to xterm :)

It is very interetsing that xterm is slower than g-t. So I expect that g-t will
also be faster than urxvt even without the bandwidth optimizaton.

Is this with gnome-terminal not refreshing every screen or does it still show
every screenful?

g-t refreshes every screen...I have urxvt 3.6 and turning off transparency did
not make much difference(avg. about 35secs). for urxvt, I think its very
conservative about the amount of data it sends to X server in one request and I
think if I change NO_SLOW_LINK_SUPPORT, I might get better results. I will post
later with that.

turning off URL highlight and g-t patch in 122656 made a HUGE difference in g-t
performance, without those and even with patch in bug 143914, I had near 100%
cpu usage when I moved mouse and 2-3 seconds delay when selecting text in a g-t
with lot of text. On solaris the slowdown is very prominent because of slower
regex impl.

urxvt +ip with NO_SLOW_LINK_SUPPORT defined: time /bin/ls -R /usr/share -> 38 secs

urxvt +ip -fn 7x13 -> 1.362 secs. its all about AA fonts, isn't it? g-t leads
the pack so far with AA.

I have never measured a slowdown of more than 3 times for aa-fonts (and
cetrainly never heard of urxvt beign slower on aa-fonts than other terminals :).
something clearly goes wrong in urxvt that, unfortunately, would require quite
some digging on your setup.

Thanks for doing the additional benchmark, the result is very interesting, It
serves to show that being fast on soem amchines does not mean being fast on all
of them (and/or that rxvt-unicode must have a big bug somewhere :)

" Reassign bug to owner of selected component "

Well, it looks like this bug is still with us, despite everyone's best efforts.
In particular I appreciate the patches here (and in bug 143914) but none of
these solve what I see as the basic problem: when text should not be scrolling,
e.g. if you are examining the scrollback buffer, or if the window is
invisible/minimized, gnome-terminal still soaks up tons of CPU time and unless
you have an extremely fast X server for your hardware, even _more_ X time.

With all that in mind, and given that gnome-terminal/vte are (IMO) far too
complex for what they actually do, I ask the following:

- Can anyone come up with a short list (5 or 10 points or so) of the things that
gnome-terminal does, which rxvt-unicode *doesn't do*? Personally, there is only
one feature of G-T I miss when using rxvt-unicode: I can't hit ctrl+shift+N to
pop up a new terminal in the current working directory.

- What would people think about dropping the current gnome-terminal code
completely, importing rxvt-unicode, and rewriting whatever functionality is
missing (i.e. the menubar+configuration, things like ctrl+shift+N etc), to have
a complete looks-alike, works-alike (but 20x faster!) replacement for
gnome-terminal. Is this crazy?

I just don't see how either gnome-terminal or vte are going to get significantly
faster without being rewritten. And since we have an almost-perfect, open-source
terminal program already (i.e. rxvt-unicode), why not adopt it? It is too good
to be ignored, I think.

there's also mlterm. opensource, transparency capable, and unicode-enough ;)

well...there is one thing that gnome-term can do and rxvt-unicode cannot:
gtk2 input modules.

if you only write in latin-based languages, this is not an issue.
but when you try to write in japanese or chinese for example you need much more
complicated input method support.
and that's where the gtk2 system uses the input modules.

rxvt-unicode only uses XIM which is far less usable than gtk2 input modules.

mlterm at least can use UIM natively, which is better than XIM, but still not
the gtk2 level.

imho this would be a stopper for rxvt-unicode or for mlterm.
because imho it's quite understandable that the gnome devels want the gnome
terminal app to be able to use the gtk2 input modules.

OK, what the heck, I use terminals (almost) every waking moment of my life....

So the previous $100 competition is over - sorry, no winners. My hope, roughly
speaking, was that someone would make gnome-terminal less stupid, not make it
act stupid more quickly. Having said that, the patches are appreciated (I do use
them, and they help) - Benjamin and Soren, I'll email you now with how you can
collect your $20 consolation prizes. ;)

Well, time for a new bounty? $100 to the first person who, before December 25
2004 (yes, it's my christmas present to myself this year...), implements
whatever extra functionality rxvt-unicode needs such that I can't distinguish it
from gnome-terminal except via performance. CHEAT: all this means is that you
have to get rxvt-unicode to do the following: 1) ctrl+shift+N pops up a new
terminal window in the current working directory, ctrl+shift+T does the same
thing but in a tab, 2) the current command appears in the title bar, 3) a menu
where the font and size can be selected using the GNOME font selector and where
the colours may be chosen using the GTK colour dialog.

A bonus $25 if your new terminal is adopted into mainline GNOME. (I guess that
means it'll need gtk2 input-method support. An extra $25 on top of that if it
leads to the old gnome-terminal being thrown out! Yes, that's a potential $150
up for grabs! Surely that covers the day or two it would take to implement. :)

Someone, anyone, please make my christmas a happy one this year. :)

So, this really needs to be gone through and patches applied. No use in having a
bunch of improvements in here if they don't get commited and released...

Absolutely. This might not be the last word on gnome-terminal, but there are
some real improvements here and they should go in. FWIW, I've been using some of
the patches (mentioned) herein for the last few weeks and they've made a
definite improvement.

The biggest problem IMO is that vte needs a backend/frontend separation.
There are lots of redraws triggered (sometimes instantly, like the scrollbar) by
random side effects and it's very hard to figure out from looking at code if
something schedules a redraw. Another bad side effect is that it sometimes
doesn't redraw even though it should (like when entering text while the CPU
utilization is peaked).

At least those were my impressions from working with the code.

"ping!"

Does anyone (Kjartan?) know if any of the patches here are going to be applied
to mainline in the near future? Or indeed, if anyone has any news at all on
things related to vte/gnome-term performance...

Duraid: VTE is totally and completely unmaintained.  The previous (it's hard to
say "current") maintainer has not reviewed any patches submitted in the last 6
months (there's been about 25 of them); many patches are well over a year old
and haven't been reviewed.  It's not that he doesn't care; it's just that he has
a lot of other responsibilities and those have taken all his time away.  We
really need to get a new maintainer.  Sven expressed interest on d-d-l; maybe we
should try to kick him and Nalin into action in transferring maintainership...

Comment on attachment 30710 [details] [review]
walk the string ourselves instead of using memchr 6+ times

This patch does not apply any longer because of other patches having been
commited. Could you check if this is still relevant and update the patch
accordingly if it is still needed?

Comment on attachment 30798 [details] [review]
second try with not updating the slider

This patch does not apply any longer because of other patches having been
commited. Could you check if this is still relevant and update the patch
accordingly if it is still needed?

I've made a test tarball with the two patches that still apply cleanly and put
it at http://www.gnome.org/~kmaraas/testing/vte-0.11.12.tar.gz

Comment on attachment 30714 [details] [review]
use a custom GTree in the xfs backend

I commited this.

Comment on attachment 30715 [details] [review]
Don't use a GArray, use a calloc'ed mem

This was commited too.

Comment on attachment 30710 [details] [review]
walk the string ourselves instead of using memchr 6+ times

Looks like a slightly different variant was commited.

Created attachment 51509 [details] [review]
scrollbar patch updated to CVS

I updated the slider related patch to CVS (hopefully I didn't break it in the
process) and that actually gave me worse results on hexdump -C somefile.png
than what I have with current CVS...

Reducing priority and severity now that most of these have gone into CVS.

*** Bug 122871 has been marked as a duplicate of this bug. ***

I've found a "funny behaviour" that is somewhat related to this.

For testing purposes I ssh:d to another box and ran a program (emerge unmerge
<kernel>) that gives massive output in the terminal so all CPU used on my
desktop should be the drawing in gnome-terminal.

This gives about 95% CPU usage on my desktop. So I thought I would minimize it
so that the output isn't shown. But that didn't do any differance, still about
95% CPU usage. Then I un-minimized it again so I would see the output, and then
I moved another window over gnome-terminal. This lead to CPU usage below 5%!

So why is CPU usage 95% when gnome-terminal is minimized but 5% when it is
covered by another window?

I should mention that this was on gnome-terminal 2.10.0.

Kjartan, do we need this scrollbar patch still?

Behdad, no need for it. GTK does not redraw the scrollbar anymore if it is not necessary. (see bug 313991)

Nice. Thanks.