Clarification: 189x24 with the initial printout was fast -- about 2.8s.
Changing the printout to include the line number made it slow.
** Description changed:
Binary package hint: libvte9
This refers to the Ubuntu 7.10 Gutsy version of vte (0.16.9). However, I
just built vte 0.16.13 (hardy), and the bug remains (I made sure it was
using the right library using strace). I refer to gnome-terminal in the
rest of the bug, but I get the exact same behavior in xfce4-terminal,
and in the vte test app.
Here's an experiment, done on an idle system (Pentium M 2 Ghz, 1GB RAM),
with gnome-terminal in the foreground, maximized. My font setup is
monospace 12, with subpixel antialiasing. My scrollback is 5000 lines.
$ resize
COLUMNS=191;
LINES=57;
export COLUMNS LINES;
$ date > XXX; time (for ((i=0;i<1000;++i)); do echo
{a,b}{b,c}{c,a}{d,a}{q,f,e}{z,c,s}; done; echo _all_)
[snip]
_all_
real 1m30.833s
user 0m0.596s
sys 0m0.012s
$ date
Mon May 12 02:33:08 EDT 2008
$ cat XXX
Mon May 12 02:31:26 EDT 2008
I typed "date" while it was scrolling, and as soon as it finished, I hit
"Enter". As you can see, "time" lies about the wall time a bit, because
the rendering is so horrendously slow. According to my "date"
measurement, the wall time is actually 1:42. My reaction time is not
that slow (see "konsole" experiment below).
Timings of the same experiment (I report the "time" value because it's
easier): 80x24 -- 1.2s, 80x59 -- 3s, 130x24 -- 1.8s, 191x24 -- 35s,
181x24 -- 2.5s, 186x24 -- 2.5s, 190x24 -- 30s.
But, if I change the string being printed (e.g. by replacing "echo ..."
with "echo $i ..."), then 189x24 suddenly becomes slow again (16s).
Maybe it depends on the pattern of spaces/newlines in the text being
displayed?
This manifests itself when I edit wide files, or cat a wide file, and
page through it. In both cases, refreshes can sometimes take as long as
5-7 seconds, even when I'm simply paging through the scrollback with
Shift-PageUp and Shift-PageDown. It seems to depend quite a bit on the
data -- again, I'm surmising something having to do with newlines or
spaces?
In fact, on the various wide data files on my disk, I feel slowness down
to terminal width 120, at which point it abruptly disappears.
I repeated the above experiments a couple of times -- the times are
fairly consistent. It did not seem to matter whether I used gnome-
terminal --geometry, or resized the window after startup.
Now, for the really weird thing. On my screen, 191x24 is almost the full
width of the screen. If I change to 6 point font, and maximize the
window to 383x112, none of these problems occur. The widest files feel
snappy, and messing with newline/space patterns doesn't change that.
Keeping the window maximized, 8pt -- still snappy, 10pt -- slight hint
of slowness, but perfectly usable, 11pt -- noticeable slowness in some
cases, but still under a second per refresh, 12pt -- catastrophically
bad.
Repeating the original 191x57 experiment in konsole (I set it up so that
it renders pixel-identical to the gnome-terminal):
real 0m1.799s
user 0m0.588s
sys 0m0.020s
- [EMAIL PROTECTED]:~/pain-genotyping$ date
+ $ date
Mon May 12 02:38:35 EDT 2008
- [EMAIL PROTECTED]:~/pain-genotyping$ cat XXX
+ $ cat XXX
Mon May 12 02:38:32 EDT 2008
Moreover, none of this slow refresh behavior is reproducible in konsole.
It's not as fast as gnome-terminal at its fastest, but it is very
consistent.
No other applications that display text have these sorts of issues.
So this is sort of a puzzler... I think it would be fascinating to know
the cause. And even better to have it fixed :)
** Description changed:
Binary package hint: libvte9
This refers to the Ubuntu 7.10 Gutsy version of vte (0.16.9). However, I
just built vte 0.16.13 (hardy), and the bug remains (I made sure it was
using the right library using strace). I refer to gnome-terminal in the
rest of the bug, but I get the exact same behavior in xfce4-terminal,
and in the vte test app.
Here's an experiment, done on an idle system (Pentium M 2 Ghz, 1GB RAM),
with gnome-terminal in the foreground, maximized. My font setup is
monospace 12, with subpixel antialiasing. My scrollback is 5000 lines.
$ resize
COLUMNS=191;
LINES=57;
export COLUMNS LINES;
$ date > XXX; time (for ((i=0;i<1000;++i)); do echo
{a,b}{b,c}{c,a}{d,a}{q,f,e}{z,c,s}; done; echo _all_)
[snip]
_all_
real 1m30.833s
user 0m0.596s
sys 0m0.012s
$ date
Mon May 12 02:33:08 EDT 2008
$ cat XXX
Mon May 12 02:31:26 EDT 2008
I typed "date" while it was scrolling, and as soon as it finished, I hit
"Enter". As you can see, "time" lies about the wall time a bit, because
the rendering is so horrendously slow. According to my "date"
measurement, the wall time is actually 1:42. My reaction time is not
that slow (see "konsole" experiment below).
Timings of the same experiment (I report the "time" value because it's
easier): 80x24 -- 1.2s, 80x59 -- 3s, 130x24 -- 1.8s, 191x24 -- 35s,
- 181x24 -- 2.5s, 186x24 -- 2.5s, 190x24 -- 30s.
+ 181x24 -- 2.5s, 186x24 -- 2.5s, 189x24 -- 2.8s, 190x24 -- 30s.
But, if I change the string being printed (e.g. by replacing "echo ..."
with "echo $i ..."), then 189x24 suddenly becomes slow again (16s).
Maybe it depends on the pattern of spaces/newlines in the text being
displayed?
This manifests itself when I edit wide files, or cat a wide file, and
page through it. In both cases, refreshes can sometimes take as long as
5-7 seconds, even when I'm simply paging through the scrollback with
Shift-PageUp and Shift-PageDown. It seems to depend quite a bit on the
data -- again, I'm surmising something having to do with newlines or
spaces?
In fact, on the various wide data files on my disk, I feel slowness down
to terminal width 120, at which point it abruptly disappears.
I repeated the above experiments a couple of times -- the times are
fairly consistent. It did not seem to matter whether I used gnome-
terminal --geometry, or resized the window after startup.
Now, for the really weird thing. On my screen, 191x24 is almost the full
width of the screen. If I change to 6 point font, and maximize the
window to 383x112, none of these problems occur. The widest files feel
snappy, and messing with newline/space patterns doesn't change that.
Keeping the window maximized, 8pt -- still snappy, 10pt -- slight hint
of slowness, but perfectly usable, 11pt -- noticeable slowness in some
cases, but still under a second per refresh, 12pt -- catastrophically
bad.
Repeating the original 191x57 experiment in konsole (I set it up so that
it renders pixel-identical to the gnome-terminal):
real 0m1.799s
user 0m0.588s
sys 0m0.020s
$ date
Mon May 12 02:38:35 EDT 2008
$ cat XXX
Mon May 12 02:38:32 EDT 2008
Moreover, none of this slow refresh behavior is reproducible in konsole.
It's not as fast as gnome-terminal at its fastest, but it is very
consistent.
No other applications that display text have these sorts of issues.
So this is sort of a puzzler... I think it would be fascinating to know
the cause. And even better to have it fixed :)
--
Wide text in wide VTE windows is extremely slow
https://bugs.launchpad.net/bugs/229465
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to vte in ubuntu.
--
desktop-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
