[nvidia] slow gtk popup menus with gtk dual head

Bug #149764 reported by thomas michael wallace
82
This bug affects 2 people
Affects Status Importance Assigned to Milestone
compiz (Ubuntu)
Fix Released
Low
Unassigned
Nominated for Hardy by TJ
linux-restricted-modules-2.6.24 (Ubuntu)
Invalid
Undecided
Unassigned
Nominated for Hardy by TJ
nvidia-graphics-drivers-173 (Ubuntu)
Invalid
Medium
Unassigned
Nominated for Hardy by TJ

Bug Description

Binary package hint: compiz

When using compiz on dual head systems context/popup menus and maximising are delayed on the first screen by approximately 3 seconds.

This seems to be a common problem : http://ubuntuforums.org/showthread.php?t=536045&highlight=compiz+slow+menus&page=2
but I couldn't find it listed as a bug.

I can confirm it isn't effected by changing the fade-menus delay in compiz (or even turning it off entirely,) and it's not altered by changing the gnome menu delay in gconf. It does not seem to be any thing to do with CPU usage / video memory as both stay quiet during the delay.

It also only happens with GTK applications, KDE apps like amarok run without any delay on both heads.

This used to happen with Beryl when you loaded it on a dual head setup using --no-context-share, and was solved by running two instances on beryl for each screen. However compiz appears to no longer has this option, nor does it seems to respect the -display :0 / -display :1 options.

Thanks, and apologies if I have duplicated a bug.

-
My setup:

Gutsy beta, last updated 6th October, bug still present.
(Compiz 0.6.1)
Using two nvidia cards with nvidia driver. (although from forum posts, this doesn't seem to be exclusively affect nvidia users.)

-

Revision history for this message
Stephan Rose (kermos) wrote :

I can second this bug report. I've had the exact same problem myself with Compiz. I have a dual-screen config running with a single 8800 GTX (2 DVI outputs) and the menu popups are just horribly slow to the point where it just becomes just unusable. Takes about 3 seconds for a menu to appear.

Running the latest Compiz version in gutsy.

Revision history for this message
Nicksha (nicksha) wrote :

I'm also having this problem in Gutsy, except that the delay is shorter (1 second). It's one card (GeForce 7600 GS) with TV-out configured as a second, separate screen. There is no delay on TV, but also no window decorations (the effects like fade, etc. are working).

OS: Ubuntu 7.10
GPU: GeForce 7600 GS
Driver: nvidia 100.14.19

Revision history for this message
Anthony DeChiaro (adechiaro) wrote :

Ditto. About 1-second delay here on drive 100.14.19. GeForce 7600GT & 6600GT running two X displays on two Dell LCDs. For me the delay is on X display 0.0 and happens on all GTK menus along with some other actions (fullscreening/restoring video in Totem for example).

My system also locks randomly too. X stops responding, but ctrl-alt-backspace works to exit out. Also have the missing window decorations on my 2nd screen (display 0.1), but I fixed it with a quick startup script from a tip on the forum:

#!/bin/sh

export DISPLAY=:0.1
emerald --replace &

Revision history for this message
thomas michael wallace (thomasmichaelwallace) wrote :

3 people have confirmed this bug, and it is reproducable.

Changed in compiz:
status: New → Confirmed
Revision history for this message
eulogycentral (uh-dpham) wrote :

I can confirm this comment also. Running 2 19 Inch 1440 x 900 Monitors on Separate X on Gutsy. One of the monitors has about a 2-3 second lag on GTK related windows/ menus. The other works fine, however, Compiz needs to be manually started on bootup for that monitor.

Revision history for this message
Emmanuel Rodriguez (potyl) wrote :

I have the same problem with an Nvidia GeForce 6200 where I have activated the second screen (VGA). I also notices that the main screen has the window decorations while the second screen doesn't.

With this setup, the menus are so slow that they are unusable. This is clearly seems to be a compiz problem because if the window manager is replaced by metacity the application menus appear instantaneously.

Revision history for this message
Pasi Savolainen (pasi.savolainen) wrote :

can confirm. Running 7200GS with nvidia_new, CRT + TV-out, this bug manifests.
Workaround suggested in forums works for me (applied from terminal on already running X):
- -
compiz --replace --only-current-screen &
gtk-window-decorator --replace &
- -

Revision history for this message
Rich (rmidwinter) wrote :

Confirmed here too. It's infuriating.

Revision history for this message
dnprossi (dnprossi) wrote :

Same Problem, tried all solutions.

Below my setup:

Mother Board: ASUS M2N-E SLI
CPU: AMD Athlon(tm) 64 Processor 3200+
VIDEO 1: NVIDIA - GeForce 7200 GS 256MB - PCI-E
VIDEO 2: NVIDIA - GeForce 7200 GS 256MB - PCI-E
MONITOR 1: ACER AL1914
MONITOR 2: ACER AL1914

Ubuntu Gutsy Release 7.10 Fresh CD Install + Updates

Used: NVIDIA restricted drivers
 Compiz
 XGL
 Manually configured xorg.conf

DUAL SCREEN Problems with different settings:

1. With XGL and "xinerama off" results in primary screen working and secondary screen black but active with X cursor. Compiz runs correctly on primary screen.

2. With XGL and "xinerama on" Top and bottom panels extend over two screens, all opened windows appear in center of two monitors (annoying). Compiz cube at center of both screens. Works if any body likes that?

3. No XGL and "xinerama on" results in primary screen with panels and no panels on secondary screen but compiz will not start.

4. No XGL and "xinerama off" results in a session per screen with menus and panels for both.
  Windows cannot be moved from one session to the other (being two sessions this is correct).
  If compiz is running it runs on both screens.
  Primary screen menus become very slow.
  Secondary screen works fine.
  Cube rotation works on both but with different settings eventhough Advanced Desktop Effect Settings
works for both displays.

Revision history for this message
TB2 (gt6) wrote :

+1, geforce 8800, same issue.

Revision history for this message
Danny Baumann (dannybaumann) wrote :

For the OP: If you want to launch one compiz per screen, you can do so by running
DISPLAY=:0.0 compiz --only-current-screen
DISPLAY=:0.1 compiz --only-current-screen

Revision history for this message
Chris Halse Rogers (raof) wrote :

Just to complicate matters somewhat, I *don't* see this bug. I'm using nvidia-glx-new, a 7600Go, and two DFPs with dynamic twinview. There's no noticable delay in the gtk popups on either screen.

Revision history for this message
Anthony DeChiaro (adechiaro) wrote :

Chris: I wonder if it has something to do with the fact you're using twinview. I'm planning to test this myself when I get a chance. Anyone else try this?

Revision history for this message
huiii (a00ps) wrote :

yesyes, i got it too
buaah
i followed the same tip as Pasi Savolainen and the delaying menus thing is gone.
but it looks not nice when starting up, makes me remember my first winter-car experience:
you turn arround the key, the car gasps and gasps and gasps and .... hey it started up!
if anybody knows what i mean..

Revision history for this message
huiii (a00ps) wrote :

sorry not Pasi Savolainen but a start-up script added to sessions which looks like this:

#!/bin/bash
sleep 5
compiz --replace --only-current-screen &
gtk-window-decorator --replace &

Revision history for this message
huiii (a00ps) wrote :

under twinview everything was OK,
no delayed menus, no need for script.
but there are other issues, like all icons and panel move to the middle of both screens so i still prefer the two seperate xscreen option where this problem arrises

Revision history for this message
Dmitriy Geels (dmig) wrote :

for everyone who complains about gnome panels on both screens and windows between two screens when using twinview:
specify 2 viewports manually in compiz settings, since it can't detect 2 monitors in twinview mode (this is nvidia hack - X see only one screen with large size)

Revision history for this message
thomas michael wallace (thomasmichaelwallace) wrote : Re: [Bug 149764] Re: slow gtk popup menus with gtk dual head

Just to note, i can confirm this isn't a bug for twinview.
As your not running multiple X screens.
However for those of us with multiple graphics cards twinview isn't an
option.

Timo Aaltonen (tjaalton)
Changed in linux-restricted-modules-2.6.24:
importance: Undecided → Medium
Revision history for this message
thomas michael wallace (thomasmichaelwallace) wrote :

can i just note, this bug is all about slow menus on the first head. for this bug everything else except the creation of popup menus and chaning window dimensions work like a charm. so i'm not sure it is a duplicate of the 'nvidia drivers slow everything' bug.

Revision history for this message
Stavros Korokithakis (stavrosk) wrote :

I can confirm this... Very irritating :/

Changed in compiz:
status: New → Invalid
Revision history for this message
Tristan Schmelcher (tschmelcher) wrote :

FYI, this bug also persists with the Hardy packages for Compiz/X/NVIDIA.

Revision history for this message
thomas michael wallace (thomasmichaelwallace) wrote :

With Hardy, the compiz seems to support the hack i used in Beryl. Here's a solution:

make a script with these two lines (i.e. ~/.compiz-dual.sh)

## start compiz
DISPLAY=:0.0 compiz --only-current-screen --replace &
sleep 3
DISPLAY=:0.1 compiz --only-current-screen --replace &

then in gnome-session-manager add a new program:
sh ~/.compiz-dual.sh

this hack just runs a simple script a log-in, if you use the defualt name it's hidden, the script restarts compiz as two seperate sessions along both heads: note the DISPLAY=#.# line. You might need to change the numbers, a quick way to test weather your screens are 0.1 and 0,0 is to run (from the terminal,):

DISPLAY=:#.# gedit

that'll open gedit on which ever screen the numbers relate to.

Changed in linux-restricted-modules-2.6.24:
status: Confirmed → Fix Released
Revision history for this message
Tristan Schmelcher (tschmelcher) wrote :

Yup, script workaround confirmed to work here on Hardy too.

Revision history for this message
Tristan Schmelcher (tschmelcher) wrote :

Confirmed still present in Hardy final.

I'm reopening this because it was mistakenly marked as Fix Released. Workarounds are not fixes.

Changed in linux-restricted-modules-2.6.24:
status: Fix Released → Confirmed
Revision history for this message
thomas michael wallace (thomasmichaelwallace) wrote :

ok, i'll admit i was a bit premature on the fix switch.

however,

some code by marriouss (http://ubuntuforums.org/showthread.php?t=536045&highlight=compiz+slow+menus&page=6) hints at a more generic script. By using a more tidier loop, or even reading xorg.conf, the code can be used to safely impliment the workaround. More over, in Ubuntu compiz is actually called using a script (compiz.real.) Therefore it would be possible to integrate this loop into compiz.real, thus no additional workarounds would be required.

I'm investigating how to quickly identify the number of screens in use, and then i'll try and get it into the official compiz.real script.

From the user's point of view this would be a fix, although it may still be argued a workaround. Considering compiz's some-what patched nature (i.e. included workarounds of openoffice menus etc.) I think this is probably the closest to a solution that can be gotten.

I'll get the modd'ed compiz.real up on this log if i sort it, anyone who know's a lil' more is welcome to try it before me :-) Then it can be tested and proposed to replace the non-dual-monitor friendly current version.

-- thanks.

Revision history for this message
Tristan Schmelcher (tschmelcher) wrote :

Ah, I see. Agreed that if this can get in to the official compiz script then that's good enough to warrant it being "fixed".

Not sure exactly what package should be marked as fixed though. I gather that this affects the case of separate graphics cards too, which makes it seem like it's not really a bug in the restricted modules package, but rather in compiz or some other component that it uses, but it's marked as invalid for compiz ...

Revision history for this message
Nigul77 (robofreak) wrote :

I am not sure if anyone else has the setup I do, but I am having the same problems, but I have 3 monitors. I have 2 8800 GTX's. 1 monitor plugged into one, and 2 plugged into the other. The one monitor that is by itself has no problems. But the 2 monitors that share the same video card does have this problem. I have tried dual monitors as twinview and seperate x screens. Both cases cause the slow menu. I ran K3B and no problems in that app so it does appear to be GTK related. Also, if I go into system-> preferences -> Appereance and select none in the visual effects, the problem goes away. But as soon as I turn compiz back on, i get the problem again. I tried the work around, didn't help. I am running Hardy Heron, with latest updates.

Revision history for this message
SerP (serp2002) wrote :

i have Hardy with latest updates, and bug is not fixed.

Revision history for this message
Nigul77 (robofreak) wrote :

Compiz had some updates a week ago or so, but problem still exists. I got the workaround to work. Unfortunately I am having problems getting it to start on startup. Tried to put it in a script and run the script on startup. Also tried putting it into the "Sessions" area of preferences.

Is there any update on this? Maybe an ETA?

Revision history for this message
Tristan Schmelcher (tschmelcher) wrote :

FYI, I do the workaround a little differently now than what's described here. Instead of having a session start-up script, I renamed /usr/bin/compiz to /usr/bin/compiz.shipped and then put the workaround script in place of /usr/bin/compiz. So my /usr/bin/compiz looks like this:

#!/bin/bash
# start compiz
DISPLAY=:0.0 compiz.shipped --only-current-screen $* &
disown $!
sleep 3
DISPLAY=:0.1 compiz.shipped --only-current-screen $* &
disown $!

You can then enable and disable compiz normally in System -> Preferences -> Appearance -> Visual Effects and it should all just work. You'll need to repeat every time they update compiz though.

I too would like some sort of update on this.

Revision history for this message
keepitsimpleengr (keepitsimpleengineer) wrote :

I tried Tristan Schmelcher's workaround (2008-07-03) and it failed causing erratic behavior with windows.

The only thing I can get to work is to execute the following commands from a terminal, and then every thing works great.

compiz --display :0.0 --only-current-screen --replace &
compiz --display :0.1 --only-current-screen --replace &
DISPLAY=:0.0 avant-window-navigator &
DISPLAY=:0.1 avant-window-navigator &

Unexpectedly, the prompt does not return after each command is executed, requiring using the enter key to force it. I also disown each of the jobs after executing them.

The first command also almost always fails as shown in the attachment, or with a segmentation error.

I attach the terminal output

Revision history for this message
Alberto Milone (albertomilone) wrote :

It might be a bug in the version of the driver that you're using.

Can you enable the hardy-proposed and hardy-updates repositories, install EnvyNG so as to install the latest release of the driver?

Let me know how it goes.

Changed in linux-restricted-modules-2.6.24:
status: Confirmed → Incomplete
Revision history for this message
keepitsimpleengr (keepitsimpleengineer) wrote :

The hardy-updates repository was already enabled.
I enabled the hardy-proposed repository, updated and had 77 updates.

I noted these changes, among the updates:
< ii nvidia-glx-new-dev-envy 173.14.05+2.6.24.501-501.30 NVIDIA binary XFree86 4.x/X.Org 'new' driver
> ii nvidia-glx-new-dev-envy 173.14.09+2.6.24.502-502.30 NVIDIA binary XFree86 4.x/X.Org 'new' driver
< ii nvidia-glx-new-envy 173.14.05+2.6.24.501-501.30 NVIDIA binary XFree86 4.x/X.Org 'new' driver
> ii nvidia-glx-new-envy 173.14.09+2.6.24.502-502.30 NVIDIA binary XFree86 4.x/X.Org 'new' driver
< ii nvidia-new-kernel-source-envy 173.14.05+2.6.24.501-501.30 NVIDIA binary 'new' kernel module source
> ii nvidia-new-kernel-source-envy 173.14.09+2.6.24.502-502.30 NVIDIA binary 'new' kernel module source
< ii avant-window-navigator 0.2.1-0ubuntu2 A MacOS X like panel for GNOME
> ii avant-window-navigator 0.2.1-0ubuntu2.1 A MacOS X like panel for GNOME
< ii awn-manager 0.2.1-0ubuntu2 A manager for the preferences of avant-windo
> ii awn-manager 0.2.1-0ubuntu2.1 A manager for the preferences of avant-windo
< ii libawn0 0.2.1-0ubuntu2 library for avant-window-navigator
> ii libawn0 0.2.1-0ubuntu2.1 library for avant-window-navigator

I still have the delay on DISPLAY=0.0, but not DISPLAY=:0.1.
compiz is working on both displays, but awn is not working on either.

Runnung the command:
compiz --display :0.0 --only-current-screen --replace &

produces an error (terminal output attached).

Rerunning the command causes compiz to work on :0.0, but not on :0.1

Running:
compiz --display :0.1 --only-current-screen --replace &
causes compix to work on :0.1

Running:
DISPLAY=:0.0 avant-window-navigator &
DISPLAY=:0.1 avant-window-navigator &
causes awn to work.

Hope this helps…

Revision history for this message
keepitsimpleengr (keepitsimpleengineer) wrote :

Updating from hardy-proposed repository breaks avant-window-navigator (both awn-manager 0.2.1-0ubuntu2 and awn-manager 0.2.1-0ubuntu2.1).

After above changes, avant-window-navigator breaks on first use:

(avant-window-navigator:7738): GLib-GObject-WARNING **: cannot register existing type `AwnTitle'

(avant-window-navigator:7738): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

** (avant-window-navigator:7738): CRITICAL **: awn_title_show: assertion `AWN_IS_TITLE (title)' failed

(avant-window-navigator:8040): GLib-GObject-WARNING **: cannot register existing type `AwnTitle'

(avant-window-navigator:8040): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed

** (avant-window-navigator:8040): CRITICAL **: awn_title_show: assertion `AWN_IS_TITLE (title)' failed
disown -a

Revision history for this message
keepitsimpleengr (keepitsimpleengineer) wrote : Re: [Bug 149764] Re: [nvidia] slow gtk popup menus with gtk dual head

Let me know if I can haul out your trash or stash your mail...

larry.j

On Thu, Jul 31, 2008 at 1:17 AM, Timo Aaltonen <email address hidden>wrote:

> ** Changed in: nvidia-graphics-drivers-173 (Ubuntu)
> Sourcepackagename: linux-restricted-modules-2.6.24 =>
> nvidia-graphics-drivers-173
>
> --
> [nvidia] slow gtk popup menus with gtk dual head
> https://bugs.launchpad.net/bugs/149764
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in "compiz" source package in Ubuntu: Invalid
> Status in "nvidia-graphics-drivers-173" source package in Ubuntu:
> Incomplete
>
> Bug description:
> Binary package hint: compiz
>
> When using compiz on dual head systems context/popup menus and maximising
> are delayed on the first screen by approximately 3 seconds.
>
> This seems to be a common problem :
> http://ubuntuforums.org/showthread.php?t=536045&highlight=compiz+slow+menus&page=2
> but I couldn't find it listed as a bug.
>
> I can confirm it isn't effected by changing the fade-menus delay in compiz
> (or even turning it off entirely,) and it's not altered by changing the
> gnome menu delay in gconf. It does not seem to be any thing to do with CPU
> usage / video memory as both stay quiet during the delay.
>
> It also only happens with GTK applications, KDE apps like amarok run
> without any delay on both heads.
>
> This used to happen with Beryl when you loaded it on a dual head setup
> using --no-context-share, and was solved by running two instances on beryl
> for each screen. However compiz appears to no longer has this option, nor
> does it seems to respect the -display :0 / -display :1 options.
>
> Thanks, and apologies if I have duplicated a bug.
>
> -
> My setup:
>
> Gutsy beta, last updated 6th October, bug still present.
> (Compiz 0.6.1)
> Using two nvidia cards with nvidia driver. (although from forum posts, this
> doesn't seem to be exclusively affect nvidia users.)
>
> -
>

Revision history for this message
Aaron Plattner (aplattner) wrote :

This is a bug in compiz. I filed a bug upstream: https://bugs.freedesktop.org/show_bug.cgi?id=17020

Changed in compiz:
status: Invalid → Confirmed
Changed in linux-restricted-modules-2.6.24:
status: New → Invalid
Changed in nvidia-graphics-drivers-173:
status: Incomplete → Invalid
Revision history for this message
TJ (tj) wrote :

Thanks for the patch Aaron. I've cherry-picked the patch (5031a1f9c91d14fbda4969781f86d806a9dd1be1) from upstream and am testing it. The patched package will be in my PPA shortly (for Hardy and Intrepid).

Assuming it doesn't create any side-effects I'll create a debdiff and see if we can get it into hardy-proposed since the patch is simple.

Changed in compiz:
assignee: nobody → intuitivenipple
importance: Undecided → Low
Revision history for this message
TJ (tj) wrote :

The patch works here, and it is a relief to have it! The packages for Hardy and Intrepid have been uploaded to my PPA for further testing.

If the next Intrepid release is from a git snapshot after 2008-08-07 will have the patch built-in and this package patch won't be required.

=== Intrepid ===
compiz (1:0.7.7+git20080807-0ubuntu6~ppa1i) intrepid; urgency=low

  * debian/patches 44: Handle sync alarm events on screens other than the last.
     from upstream commit 5031a1f9c91d14fbda4969781f86d806a9dd1be1
     (closes LP #149764).

 -- TJ <email address hidden> Thu, 4 Sep 2008 03:30:00 +0100

=== Hardy ===
compiz (1:0.7.4-0ubuntu8~ppa1h) hardy; urgency=low

  * debian/patches 44: Handle sync alarm events on screens other than the last.
     from upstream commit 5031a1f9c91d14fbda4969781f86d806a9dd1be1
     (closes LP #149764).

 -- TJ <email address hidden> Thu, 4 Sep 2008 03:30:00 +0100

Changed in compiz:
status: Confirmed → In Progress
Revision history for this message
Aaron Plattner (aplattner) wrote :

Thanks, TJ. I just installed your PPA build and can confirm that it works.

Revision history for this message
TJ (tj) wrote :

SRU Justification:

Impact: When using compiz on dual head systems context/popup menus and maximising are delayed on the first screen by approximately 3 seconds. Additionally, there is around one second delay for each menu pop-up action, dialog display, or window creation.

Testcase: Desktop Effects enabled on a dual-screen (multiple X screens) system, expand any main menu item and drill down. Each new menu pop-up is delayed by around a second when on the primary screen. Doing the same operation on the secondary screen the pop-ups appear immediately.

After applying this patch the menu pop-ups appear immediately on the primary and secondary screens.

Changed in compiz:
assignee: intuitivenipple → nobody
Revision history for this message
John Dong (jdong) wrote :

Patch is reasonable but versioning is incorrect -- you should use 0ubuntu7.1 for SRU's.

Revision history for this message
TJ (tj) wrote :

Corrected patch version for SRU (0.7.4-0ubuntu7.1).

Revision history for this message
John Dong (jdong) wrote :

Getting there. Please make patch against hardy-proposed

Revision history for this message
chewearn (chewearn) wrote :

Running Intrepid beta with NVIDIA restricted driver and Separate X screen.
Just got a huge dist-upgrade. This bug is now solved for me.

Revision history for this message
Samuel Batista (samuel-megamen) wrote :

Hi gents, I also have this problem. Yesterday I spend the entire night running scripts to try to solve it. My system became so erratic and unusable that I had to reinstall Ubuntu. I would like to install the patch proposed by TJ but being new to Linux I have no clue how to install .diff files. Will someone help me please?

Revision history for this message
Rush Tonop Online (rush-online) wrote :

I don't know how to make all that things right, but I've applied Aaron Plattner patch to Michael Vogt compiz 0.7.6 and solve this problem.

I'll now try to add self-made package to my PPA, may be anyone can help me to do it ?

Revision history for this message
Krzysztof Klimonda (kklimonda) wrote :

@John Dong: I can see that this patch still didn't make it to the hardy-proposed. what else (that changing hardy to hardy-proposed) has to be done to move this bug further?

Revision history for this message
Travis Watkins (amaranth) wrote :

This is fixed outside of hardy. Please open a separate hardy task if you still plan on getting this in as an SRU.

Changed in compiz (Ubuntu):
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.