194959 - restoring from taskbar is slow with nvidia driver version 4.0.7.2

Status: RESOLVED DUPLICATE of bug 176940

(SeaMonkey :: General, defect)

Description

[Jim King]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030225
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030225

I have a Navigator window and a Mail & News window open.  If I click on the
windows themselves they instantly activate (come to the foreground, get focus,
etc.).  If I activate one of them by clicking on its icon on the taskbar there
is a long delay (5 to 10 seconds) where nothing happens, then the window
suddenly activates.  I get the same results whether the windows are minimized or
showing.  I get the same results on this build as well as 1.2.1 and 1.3b.

Reproducible: Always

Steps to Reproduce:
1. Open two windows
2. Click on icons in taskbar to activate windows


Actual Results:  
Windows activate after long delay

Expected Results:  
No delay

- PC is dual processor P4 Xeon
- video card is Nvidia Quadro4 700 with two monitors
- video driver is Nvidia version 40.72
- No other apps show this behavior

Comment 1

[kaldari]

*** Bug 194990 has been marked as a duplicate of this bug. ***

Comment 2

[Gavin Sinclair]

Confirmed with windows XP and latest 1.3 branch and trunk - I have delay in
repainting chrome when switching between mozilla windows using the taskbar.

Using alt-tab; clicking non-maximised windows or using the Window menu will
change immediately without problems.

I have disabled XP effects and use the maximised performance settings for
transitions and menu effects governed by XP.

1 Ghz athlon 512Mb Ram and Nvidia Geforce4 MX 420 (Driver 4.0.7.2)

Comment 3

[Gavin Sinclair]

I have gone back to an earlier driver for my Nvidia graphics card. There is no
longer any delay in switching between windows - whereas it was making switching
by the taskbar unusable with the 4.0.7.2 driver.

Mozilla was the only application that seemed to have problems with the driver.

Comment 4

[Jim King]

I'll confirm the better behavior with an earlier version of the Nvidia driver. 
With 30.84 (aka 3.0.8.4) the delay is gone.

I'll also confirm that Mozilla is the only application that exhibited the
problematic behavior with the newer Nvidia driver.

Comment 5

[Gavin Sinclair]

I've been to www.nvidia.com and downloaded their recommended latest drivers (as
opposed to those endorsed by MicroSoft). Running with driver version 4.1.0.9
does not have any delay in changing between windows.

Haven't used it enough to see if there are any down-sides to using this driver.

Comment 6

[Daniel Wang]

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

Comment 7

[Gavin Sinclair]

Bug 76831 comments suggest this is a separate 'bug'. 

The problems described in this report are limited to a certain graphics card and
driver - and do not only occur after a long period of inactivity.

Suggest this is not a dupe. Suggest summary should be 'Switching window from
taskbar is slow with Nvidia Driver 4.0.7.2 / 40.72'

Comment 8

[Michael Lefevre]

agree that this probably isn't a dupe of that one.

however, it sounds like this was a bug in a particular version of the nvidia
driver that is easily avoided by using an older/newer driver. no sense in
changing mozilla to workaround other people's bugs when there are easy workarounds.

I'd say this should be WONTFIX/INVALID, but I'll leave that for someone else to
decide...

Comment 9

[Gavin Sinclair]

This should be duped against Bug 176940 - which picked up the probem with the
drivers when they were in the development stage.

I suspect there could be more reports of this as the 4.0.7.2 drivers are now
released and downloaded by Windows Update. Even if technically a bug with the
drivers and it should be invalid, having that bug open will allow anyone else
coming accross this to find the workaround.

Except that I didn't find it until now - probably due to using a default query
without searching unconfirmed bugs.

Comment 10

[Chris Lyon]

agreed

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