Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 110154 - vte 0.11.x is slow
vte 0.11.x is slow
Status: CLOSED DUPLICATE of bug 132770
Product: Fedora
Classification: Fedora
Component: vte (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Ray Strode [halfline]
: 75478 135672 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2003-11-15 09:09 EST by Peter Zelezny
Modified: 2007-11-30 17:10 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-21 14:00:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Peter Zelezny 2003-11-15 09:09:34 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Gecko/20031030 Galeon/1.3.10

Description of problem:
After noticing slow compile times, I tracked it down to vte. It's
actually taking alot of time rendering what gcc spits out. The hit is
pretty substantial. Using a test of "time rpm -qa", I got these results:

xterm: 3.6 seconds
xterm with FreeType font (AA): 4.5 seconds
rxvt: 3.6 seconds
vte-0.11.10-4: 11.3 seconds
linux console: 3.1 seconds

Obviously vte is doing alot (UTF-8, AA et al.), but I believe vte
0.10.x did much better than this.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Open gnome-terminal
2. time rpm -qa
3. watch it scroll for too long.

Additional info:
Comment 1 Dumitru Ciobarcianu 2004-02-06 01:44:45 EST
Confirming on big compiles. 
vte takes time to render all the text he has in the queue.

Afair if xterm has a long display queue it just "skip" to the current
output. That makes sense?
Comment 2 Thomas M Steenholdt 2004-07-01 16:38:08 EDT
This bug is valid for core 2 as well... and very annoyoing too!

I've seen it discussed on bugzilla.gnome.org but no real solution
seems to have come out of any of it!

to me this bug is important to get fixed... I frequently do some
programming in vi under a gnome-terminal (or at least i would, had it
performed properly) but scrolling up/down is just to painfully slow,
when browsing the code for instance.

please update severity as this effectively renders gnome-terminal
useless. Also, please bump version to devel, as the problem is stille
not fixed.
Comment 3 Havoc Pennington 2004-07-03 07:31:06 EDT
It doesn't make gnome-terminal useless, thousands of people use it
daily. Having a bug open for "make things faster" is not really useful
since it isn't a specific well-defined task, and bugzilla is a task
tracker; really the bug we need open is "the following function shows
up in a profile and can be optimized in the following way" Lots of vte
optimization has been done, what fixes are still possible is an open

We have accelerated the RENDER extension in X.org server, which should
make a big difference.

Comment 4 Need Real Name 2004-10-18 02:53:34 EDT
gnome-terminal isn't useless, but it is really slow.

real    0m19.997s

real    3m54.364s
Comment 5 Need Real Name 2004-10-18 02:54:22 EDT
*** Bug 135672 has been marked as a duplicate of this bug. ***
Comment 6 Ray Strode [halfline] 2004-11-04 00:26:09 EST
*** Bug 75478 has been marked as a duplicate of this bug. ***
Comment 7 Rick Richardson 2004-11-04 01:25:33 EST
Havoc, this bug has existed in gnome-terminal ever since RH8.  The
gnome-terminal in RH 7.2 did not have this problem. xterm has never
had this problem.

Accelerating the RENDER extension in the X.org server is NOT an
acceptable fix.  Expecting newer, faster hardware to cover up sloppy
programming and/or design is the Microsoft way, and that way has no
business in our world nor in the attitude of one of the leaders in our
Comment 8 Ray Strode [halfline] 2004-11-04 01:48:39 EST
Hi Rick,

The "vte is slow" problem is a problem that is being addressed.  There
are a number of performance patches out there that are being looked at
and added (see bug 132770 for instance).
Comment 9 Need Real Name 2004-11-04 03:24:25 EST
bug 132770 says the speedup patch is in rawhide..
A cached "find /" on xterm is *ludicrously* faster.

Also, xterm doesn't have the weird "page up" ghosting bug when viewing
a text file with less.
Comment 10 Warren Togami 2004-11-15 21:14:18 EST

*** This bug has been marked as a duplicate of 132770 ***
Comment 11 Red Hat Bugzilla 2006-02-21 14:00:01 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

Note You need to log in before you can comment on or make changes to this bug.