Dual Monitors Windows 7 Problems

Question

Ok, this problem is getting really annoying and I think its a problem with windows 7 itself and not my computer.
Basically I have a dual monitor setup with the left hand monitor as my secondary and right hand monitor as my primary.  Whenever I have an application with any graphics on it at all such as a progress bar on my left hand monitor moving windows around becomes laggy and juddery, yet this doesn't happen when the graphical app is on my primary monitor!
My system Specs: 
ASUS Striker Extreme MOBO
OCZ 850W gameXtreme
Core 2 Duo 2.4GHz CPU
4GB (4x1GB) OCZ DDR2 1066MHz RAM
Nvidia 8800GTX
Sound blaster x-fi Xtreme Gamer (older PCI version)
3 x 80GB HD for system drive in RAID 0
1 x 500GB and 1 x 250GB drives for storage
Monitors are 1680 x 1050 res
Windows 7 Exp Index:
CPU: 5.9
Memory: 5.9
Graphics: 6.8
Gaming Graphics: 6.8
Primary HD: 5.9
What iv tried:
Updating to latest drivers
Upgraded system memory from 2GB to 4GB
Installing 64-bit version
removing sound card and re-installing windows from scratch
upgraded my PSU
Thanks for your help!

Answer 1

(Latest update) This is the best I can do to alleviate the problem, and does reduce its severity immensely, but I found myself still noticing some slight playback glitches in videos on my second monitor which probably also translate to anything else with movement. I have tested with a panning scene in one of my videos and there is a subtle micro-stutter on my second monitor which I can find no way to fix. This doesn't occur if outputting to a single display, one or the other, nor does it occur when playing the video on my primary monitor in a dual-monitor configuration. Note that when I say "primary monitor", I am not referring to the monitor Windows has marked as primary, but my actual monitor rather than TV. In a dual-monitor configuration, this micro-stutter will only occur when playing video on my right monitor (TV), regardless of settings or which ports the monitors are connected to on the GPU. The micro-stutter occurs with no relation to the activity on the other screen, as it can be completely still. I can confirm the micro-stutter does not occur at all with Desktop Window Manager (Aero) disabled. In short, this is a nightmare.
(Note that this micro-stutter is equally replicable in the 182.50 (WDDM1.1-less) driver, meaning there is no way to solve it other than disabling Aero or outputting to a single monitor.)
I think I've solved the problem.. for me, anyway. I've divided this into short answer and "long answer", which is closer to a stream of consciousness in some ways, as I found out about Force10Level9 as I was writing.
The short version:
I've found some registry keys which seem to have fixed the problem for me. I haven't experienced any side effects, but use the tweaks at your own risk!
I don't know exactly what they do. This comes from a lot of.. experimentation. I believe FrameRateMin tells the Desktop Window Manager that it's crucial to try to keep the framerate at or above the value specified (more details below), and Force10Level9 sounds like it forces DWM to use DirectX 9. I'm fairly certain about the former, not as certain about the latter, but together they do wonders.
You can view the fix below. You can then save it as a .reg file and import it into your registry. Restart the Desktop Window Manager service or reboot to see the changes.
Fix: http://pastebin.com/FFDbubw9
Undo: http://pastebin.com/zA8CJY06
(P.S. Just ran a FurMark test between fix applied and no fix. No difference in performance, with an inactive secondary monitor. I also noticed no difference in Physical Memory usage as reported by Task Manager. YMMV, let me know if you have any side effects.)
(P.P.S. The screen fade that happens when you log in/out is just as choppy as before (or if it wasn't choppy for you, that shouldn't have changed). Oh well, how often do we see that thing, anyway? :))
By the way, it appears 10Level9 is Windows 7's emulation platform for running DX10 on DX9 hardware. It's reported to be at least a 0.5x performance hit, so it's surprising that it actually makes Aero run better. If this article is anything to go by, Force10Level9 makes Aero run exactly the same as it does with older WDDM 1.0-only drivers like 182.50: http://www.techarp.com/showarticle.aspx?artno=637&pgno=1
The long version:
Well... I was able to do one more thing.
There is an undocumented registry key which allows you to fine-tune the Desktop Window Manager's scheduling. Unfortunately, all of its values seem to be defunct in the final version of Windows 7 we all use today... except one: FrameRateMin.
From what I gather, the Desktop Window Manager (Aero) carefully monitors the framerate it is able to achieve, and when it can't measure up to its own expectations, it will perform a "step down", or framerate reduction, and maintain this lower framerate for a given period of time (at one time specifiable with a registry value) before trying again at maximum speed.
I presume it does all this to keep things looking "smooth".
The problem is, in most cases, it doesn't help, and actually prolongs the stuttering duration. By "in most cases", I mean in every case it's happened in my personal usage of my Windows 7 computers.
So what helped me was setting this FrameRateMin value to 60. That way, the Desktop Window Manager considers anything under 60fps to be unacceptable and will not remain at a lower framerate for purposes of perceived smoothness. Thus, the stuttering will take up as little time as possible, making it nearly unnoticeable most of the time.
Keep in mind DWM shouldn't be having performance problems to begin with, but apparently in some cases, like with my particular hardware (desktop and laptop) and the latest NVIDIA drivers, it does.
Down to brass tacks. The registry key is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\DWM\Schedule. The value is FrameRateMin, a DWORD representing the minimum framerate DWM will consider as acceptable. I set it to 60, but you can set it to whatever you want.
To repeat, this WILL NOT prevent Aero from ever getting below the framerate you specify; it simply prevents Aero from retaining a lower framerate after a stutter in order to give the illusion of smoothness (an illusion which fails).
I imagine the main reason it fails so spectacularly in my usage is because I watch a lot of videos which play back at 24fps. Such a framerate plays back terribly with a 30Hz refresh rate, which is what Aero would reduce itself to for extended lengths of time. Now, performance hiccups are minimal, but sadly still existent.
So this isn't a solution, but it does help. I am still uncertain of where the problem lies, considering GPU-Z shows graphics card loads to be as low as always when it's happening.
Oh, and I found one more registry value. This one is far more important. :) It solves the problem for me entirely, from what I can tell.
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Avalon.Graphics
add the DWORD value Force10Level9 with a value of 1.
I haven't noticed any side effects, just smooth performance.
Apply these tweaks at your own risk!