GNOME Bugzilla – Bug 124544
After some time of live cycle gnometerminal text selection is too slow
Last modified: 2004-12-22 21:47:04 UTC
Imported from FreeBSD GNATS (ports/54817): http://www.freebsd.org/cgi/query-pr.cgi?pr=54817 % pkg_glob gnometerminal gnometerminal-2.2.2 % open gnometerminal (single tab). % su # cd /usr/ports/www/mozilla-firebird # make ... # by top process in state RUN while it happens by strace I can't see someting special. If gnometerminal live longer it becames slower and slower. try to select some text - see delay between beginning of selection and finish (about 1/2 sec for 1Gz Pentium III) Audit-Trail: Responsible-Changed-From-To: freebsd-ports-bugs->gnome Responsible-Changed-By: arved Responsible-Changed-When: Mon Jul 28 02:00:16 PDT 2003 Responsible-Changed-Why: Over to maintainer http://www.freebsd.org/cgi/query-pr.cgi?pr=54817 State-Changed-From-To: open->closed State-Changed-By: marcus State-Changed-When: Mon Oct 13 20:26:18 PDT 2003 State-Changed-Why: gnome-terminal 2.4.x with vte 0.11.x has been greatly improved. If the problem persists, try building vte with -DWITH_GLX (provided your card supports DRM). ------------------------ Nothing changed about PR: % pkg_glob gnometerminal vte gnometerminal-2.4.0.1 vte-0.11.10_1 % <<cut from top>> 906 vova 115 0 23396K 17440K RUN 0:49 48.93% 48.93% gnome-terminal No other active process, no swapping activity, just select some lines of text by mouse. Selectin takes about 3 seconds to be displayed in terminal window. Gnome-Terminal is completely unusable in my case. terminal font is "fixed" (so no any TTF rendering). Terminal have only one tab. I am run 5-CURRENT (fresh cvsup). > If the problem > persists, try building vte with -DWITH_GLX (provided your card supports DRM). Frankly speaking I do not think that GLX can help me, I have neomagic video chip in my notebook and it have no any GLX. My notebook configuration: CPU: Pentium II/Pentium II Xeon/Celeron (331.58-MHz 686-class CPU) Origin =3D "GenuineIntel" Id = 0x66a Stepping Features=3D0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA, OV,PAT,PSE36,MMX,FXSR> real memory =3D 201261056 (191 MB) avail memory =3D 185790464 (177 MB) It is sufficient to run on normal speed (usually in parallel): - gnome environment (including nautilus) - evolution - licq (with qt/kde gui) - xemacs - mplayer or xmms - one or two of mozilla/galeon2/firebird/opera(linux) with jvm - openoffice or gnumeric - a lot of xterms - do regular make world && portupgrade -a -x openoffice There is only two places where speed is too low: - gnome-terminal (completely unusable) - evolution composer (I have reported this before) while change focus between To:/Cc:/Subject lines (all other functions, including spell-check work fast enough) PS: Just check gnome-terminal on much faster machine, same problem, I have run in terminal window 'ls -lR /sys/' Then try select some lines, it pauses for 1-2 secs (I am sure it is too much for this machine) <<cut from top>> 25830 vova 41 0 21188K 16864K RUN 0:21 34.98% 34.96% gnome-terminal % uname -r 4.9-PRERELEASE dmesg output: CPU: Intel Pentium III (938.03-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x686 Stepping =3D 6 Features=3D0x387f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA, OV,PAT,PSE36,PN,MMX,FXSR,SSE> real memory =3D 268349440 (262060K bytes) avail memory =3D 254976000 (249000K bytes) GLX disabled too. After enabling GLX ( I have TNT2 here ). I can't notice any delay by select text, but CPU usage still too high (for my taste): <<cut from top>> 29468 vova 39 0 19452K 13288K RUN 0:12 11.24% 11.08% gnome-terminal PPS: Do anybody use gnome-terminal without GLX ? May be I need to disable GLX while build some port. ------------------------ From: Jeremy Messenger <mezz7@cox.net> Well, I still think you should contract to the Gnome team. Those issues are known on Linux too, but it's much improvement in the lastest version. Therefore, I think it's reasonable to close this PR. ------------------------
Sounds like there are some BSD-specific problems- might want to look at bug 122871. *** This bug has been marked as a duplicate of 122871 ***