gnome-terminal reacting very sluggishly

I noticed the same problem here

Same here with a fresh Herd 4 install.
High CPU usage during scrolling.

A further data point: side by side I open two terminals. In one I have `top' running. In the other I do someting to make the terminal screen scroll. In `top' I can see that Xorg's cpu usage converges to 100 %.

#v+
$ while sleep 1 && seq 0 20 | tr \\n \ && echo; do :; done
#v-

... for example gives a Xorg cpu usage of 40 %, which is too much in my understanding.

I tried with the edgy version of gnome-terminal (2.16.1-0ubuntu1) and get the same issue, so I don't think it's really a gnome-terminal issue. Could someone also try with the edgy version?

Laurent,I tried with edgy version and yes the same issue.
Also scrolling in the terminal of Synaptic react very slow !

Indeed this is not just an issue with GNOME Terminal. I have seen similar problems with XFCE's terminal. As Konsole does not show these issues, it is likely related to the GTK+ family of libraries (which both GNOME and XFCE use).

It's maybe a pango issue or something

Could be a vte issue. Does Xfce use it?
The changelog for it actually states massive improvements with vim. I experience the opposite.

Yes, both GNOME Terminal and XFCE4 Terminal use VTE. Konsole does not.

Installed a daily build (170207) and the same problem.
There is something wrong !

Has anyone been able to confirm if this is a VTE issue, or an issue with another of the GTK+ libraries?

I think this is related to bug #85956

I've rebuild vte with the patch from gnome BTS and it seems that gnome-terminal is a lot more reactive. Could someone confirm? BTW xorg still use a lot of cpu

I'm experiencing this too since 20070220 Feisty daily updates, VTE and X client (1.2.0?) updates were pulled in. Scrolling in terminals is significantly slower and also it seems like Beryl glitches after that update too

I will later today try rolling back updates and trying to isolate a culprit.

Not just slower, but there is also screen corruption (missing/partially drawn characters).

If I revert to the edgy versions of `libvte9' and `libvte-common' (i.e. the 1:0.14.1-0ubuntu1 versions), everything seems to be fine again.

After a bunch of updates today gnome-terminal reacts normally for me.
Anyone confirm this?

this is fixed for me on recent vte update

Not quite fixed, as the screenshot shows (incomplete status bar, what looks like a cursor block over my typing).

Fixed in 1:0.15.4-0ubuntu1 according to changelog. Maybe open a new bug for the terminal corruption

Reported.

https://launchpad.net/ubuntu/+source/gnome-terminal/+bug/88504

I'd like to have this issue revisited, as I don't consider it fixed.

Test case: a freshly booted system, X server and one full screen Gnome terminal running ``top -d 1''.

Edgy versions (`1:0.14.1-0ubuntu1') of `libvte9' and `libvte-common': cpu running at 600 MHz and `Xorg' uses 5% cpu time. This is still too much for my feeling, but I can certainly live with that.

However: current Feisty versions (`1:0.15.4-0ubuntu1') of `libvte9' and `libvte-common': cpu running at 1700 MHz and `Xorg' uses 34% cpu time.

With a recent upload, this is fixed now.

And in fact, this report seems to be a duplicate of <https://launchpad.net/bugs/78343>.

Sorry, but despite getting a lot better, this is still broken for me. I just downgraded from 1:0.15.6-0ubuntu1 to edgy because the lag in interactive use was driving me crazy.

James: You are right. It's a lot better, but there is still a very noticeable (read: annoying) delay when switching between different tabs.

So, what can we do to get this ticket reopened and the issue revisited?

Could somebody work with upstream on that, they know the code better and the Ubuntu Desktop Team is overworked at the moment

Using +/- keys to scale font size seems to be extremely sluggish also, likely related. At it's worst, the entire terminal goes white and will render the text only after switching tabs and/or moving cursor over the window.

I'm seeing corruption of a different kind, where sections of other windows randomly reappear within my gnome-terminal. If I make the font smaller, it seems to stop, and repainting the screen also removes the corruption.

Dropping the milestone, we are too near of 7.04 to do changes on that now. Does anybody still get the bug or is that been fixed with updates? Do you have an easy way to trigger it, we might get a fix to feisty-updates if that's still happening

On 4/13/07, Sebastien Bacher <email address hidden> wrote:
> Dropping the milestone, we are too near of 7.04 to do changes on that
> now. Does anybody still get the bug or is that been fixed with updates?
> Do you have an easy way to trigger it, we might get a fix to feisty-
> updates if that's still happening

For me it seemed more likely to happen with very large font sizes...

--
Martin

Actually it happened again at my regular font size. What's interesting is that it's often getting overlayed with content from some other window, in this case the task switcher.

I rebuilt vte (1:0.16.3-0ubuntu1) from gutsy's archive for feisty and for me it seems that terminal response time has improved significantly.
Anyone experiencing problems with feisty's vte should probably try this out too. Maybe we could get this to feisty-backports (or as SRU).

mlind: Where did you get that version from? On <http://packages.ubuntu.com/gutsy/libs/libvte9> I see 1:0.16.1-0ubuntu1 listed as the latest, which is the same that feisty has.

$ apt-cache madison vte
       vte | 1:0.16.1-0ubuntu1 | http://www.nic.funet.fi feisty/main Sources
       vte | 1:0.16.3-0ubuntu1 | http://archive.ubuntu.com gutsy/main Sources

mlind: You are right that with such self-compiled packages, the resource consumption and respons times are fine again.

However, I'm still (irregularely) seeing the same screen corrupotion as reported my Martin Pool.

yes, screen corruption is still there for me too.

New vte from gutsy's archive is working really well for me, screen corruption seems to be fixed too. Would it be possible to get this backported for Feisty?

The gutsy version works fine, marking fixed. You can open a feisty-backport bug if you want

Added a backport request

-> Considering build-dep gnome-pkg-tools (>= 0.10)
      Tried versions: 0.9.3
   -> Does not satisfy version, not trying

With gnome-pkg-tools backported, it b/i/r well.

Putting it in Incomplete until someone accpets gnome-pkg-tools bug.

Bishiboosh, are you sure you tried the vte in Gutsy's archive? It doesn't have versioned b-depends on gnome-pkg-tools, but the vte in Debian unstable has.

gnome-terminal
Reverse Depends:
 |gnome-panel
  wajig
 |sawfish
  meta-ul-server-gui
  meta-ul-desktop-base
  gnome-rdp
  gnome-core
  anjuta
  ubuntu-desktop
  gnome-terminal-data
  gnome-terminal-data
 |gnome-panel
  edubuntu-desktop

I think this is to much a core application for a safe backport. Certainly for a backport for whatever is left of the issue that may or may not be related to this package. Backports is intended to bring new features, not bug fixes.

I have a problem with my gnome terminal. I run the terminal and execute the script "sudo bash diskmount" After I do that I get a new line saying ONLY "Password:" and I cannot complete the field to finish running the script, It also makes it respond very slowly, and the only way to run scripts again is to open a new terminal.

It seems I experience the same issue on ubuntu Jaunty and gnome-terminal 2.26.0.

I'm also experiencing this with 9.04 in vte-based terminals but only when more than one tab is opened, the behavior is not present if I have only one tab opened