Bug 110154 - vte 0.11.x is slow
Summary: vte 0.11.x is slow
Status: CLOSED DUPLICATE of bug 132770
Alias: None
Product: Fedora
Classification: Fedora
Component: vte (Show other bugs)
(Show other bugs)
Version: 1
Hardware: All Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
: 75478 135672 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-15 14:09 UTC by Peter Zelezny
Modified: 2007-11-30 22:10 UTC (History)
6 users (show)

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

Attachments (Terms of Use)

Description Peter Zelezny 2003-11-15 14:09:34 UTC
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 06:44:45 UTC
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 20:38:08 UTC
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 11:31:06 UTC
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 06:53:34 UTC
gnome-terminal isn't useless, but it is really slow.

real    0m19.997s

real    3m54.364s

Comment 5 Need Real Name 2004-10-18 06:54:22 UTC
*** Bug 135672 has been marked as a duplicate of this bug. ***

Comment 6 Ray Strode [halfline] 2004-11-04 05:26:09 UTC
*** Bug 75478 has been marked as a duplicate of this bug. ***

Comment 7 Rick Richardson 2004-11-04 06:25:33 UTC
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 06:48:39 UTC
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 08:24:25 UTC
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-16 02:14:18 UTC

*** This bug has been marked as a duplicate of 132770 ***

Comment 11 Red Hat Bugzilla 2006-02-21 19:00:01 UTC
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.