I think it is hasty simply to say "It's just the nVidia driver."
1) Firstly, it is clearly not a performance issue, as the exact same issue occurs on all chipsets, in the same way. This wouldn't be the case if it was simple performance.
2) When I run 3D games on the same system, from KDE, which are massively more taxing in terms of graphics, I can easily get perfectly smooth animation without any tearing at all.
3) The tear line (for me at least) is in exactly the same place on the screen all the time, about 10% from the top, or so.
4) The tear line appears to have a Z shape to it, actually back tracking, then continuing on its way across the screen a small distance further down the screen - others have reported this as well.
I cannot explain point 4 at all, it makes no sense whatsoever unless it is an artifact of the way my LCD scans out the image (this makes no sense either) so I'm just going to leave that point hanging and unexplained!
Point 3, to me, seems to suggest that the Vsync is working perfectly, and that the Vblank interval is more than sufficient for OpenGL to redraw the graphics before flipping the screen. The only explanation I can offer is that the graphics task is well within the card's capabilities, and the Vsync works, however it seems to be syncing it to the wrong time. ie the flip of the frame buffers is happening a set interval after screen re-refresh starts.
My take on all this is that it cannot be purely the driver due to point 2. So perhaps it is a combination of how the Orbiter code interacts with the driver in some way. One other point floating around in my mind is that I seem to recall that LMCE was switched from Ubuntu to Kubuntu and thus GNOME to KDE expressly because the KDE interface allowed graphics acceleration within the second + "virtual desktops" that LMCE runs within, and there was some kind of limitation on this within GNOME. I wondering if perhaps there is some issue in screen flipping when the Orbiter is animating to screens that are not the main KDE desktop screen...
I know this doesn't help fix the issue, just thought I would document my toughts on it, particularly the ones that seem to point away from a simple driver issue ... although if my last pondering is something to do with it, then perhaps it is a driver/KDE issue?
