Red Hat Bugzilla – Full Text Bug Listing
|Summary:||gnome terminal slow|
|Product:||[Fedora] Fedora||Reporter:||jonathan baron <baron>|
|Component:||gnome-terminal||Assignee:||Behdad Esfahbod <behdad>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-10-15 03:37:30 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description jonathan baron 2007-07-30 09:59:09 EDT
Description of problem: slow at first displaying text, e.g., when switching to its window Version-Release number of selected component (if applicable): gnome-terminal-2.18.1-1.fc7 How reproducible: always Steps to Reproduce: 1. use gnome terminal 2. it may be necessary to use large fonts and a large window. I use DejaVu Sans Mono 20. 3. Actual results: screen is blank for some large fraction of a second before starting to display Expected results: as fast as it was on Fedora Core 6 (and still is on another computer I haven't yet upgraded). Additional info: The problem is fixed by removing anti-aliasing, e.g., with the following .fonts.conf file. I'm not sure that both changes are needed. I think the rgba one is the crucial one, but I didn't test it. <?xml version="1.0"?> <!DOCTYPE fontconfig SYSTEM "fonts.dtd"> <fontconfig> <match target="font"> <test name="family" compare="eq"> <string>DejaVu Sans Mono</string> </test> <edit name="antialias" mode="assign"> <bool>false</bool> </edit> <test name="family" compare="eq"> <string>DejaVu Sans Mono</string> </test> <edit name="rgba" mode="assign"> <bool>none</bool> </edit> </match> </fontconfig> Note, again, this is a new problem. Gnome-terminal worked fine in the version on FC6.
Comment 1 jonathan baron 2007-07-31 06:16:13 EDT
I no longer think that the problem is with antialiasing. I think that was a coincidence. I am now using antialiased fonts and see no difference. Also, I notice that the problem occurs mostly (only?) when I switch to a terminal window that contains lines that run off the screen, such as the subject lines of mutt email messages. This is also true in the development version of gnome-terminal (2.18.1-1.fc8), which I am now using. It is also clear that the problem of slow displays is limited to gnome terminal. All other applications that I use (firefox, xemacs, etc.) work fine so far. (xterm works fine too, but I am resisting switching to it because of my habit of using Gnome's cut/paste system.)
Comment 2 jonathan baron 2007-08-03 06:24:43 EDT
This bug is probably not in gnome-terminal after all. I installed the current version of gnome-terminal for FC6, which works fine on other computers (which will now keep FC6 as long as possible!), and I still have the same problem. I don't know where the problem is, possibly in the X server (which has other problems like not suspending).
Comment 3 jonathan baron 2007-08-04 15:51:52 EDT
Further tests reveal that the problem is due to large fonts (required if yor are over 30 years old). If I use the system fixed font set to 10, everything is fine. If I enlarge it to 20, the problem returns, as does this setting with any other font. I'm getting used to xterm, which works fine. I'm not too old to learn yet another system for cutting and pasting, even though I'm too old to see these tiny fonts. The problem is specific to gnome terminal, but, as I said, installing the FC6 version of gnome terminal doesn't help.
Comment 4 jonathan baron 2007-10-15 03:37:30 EDT
Nobody has commented on this bug, so probably nobody has replicated it. Indeed, I have now installed Fedora 7 on another system and not noticed a problem. This made me suspect that something was wrong with my video setup. I made a few changes in xorg.conf, and now everything seems to work OK. So maybe someone should close this bug. I will try. FWIW, the changes were: load "dbe", in Module section Option AIGLX "on", in ServerFlags XAANoOffscreenPixmaps "true" in Device Option "Composite" "Enable" in Extensions I'm using the fglrx driver. I think the XAANoOffscriptPixmaps may have been the important one, but I didn't test them one by one.