I thank God for showing me the solution! All you have to do is add a "false foot" bone that is NOT a deform bone to each leg. I named this bone FootParent.

After further investigation, I believe my issue is directly related to this issue. Apparently, when exporting to FBX, you cannot both scale and rotate the parent bone, even if the child has Inherit Scale and Inherit Rotation turned off. It would be great to see a fix for this present limitation somehow.

You're welcome. Thanks for looking into this. I'll remember to break issues up next time.

Thanks guys! Don't forget to check the link to the video example. It shows pretty clearly how the different bugs react. My apologies for becoming braindead momentarily in the video when switching between bug subjects, LOL, that was my first-ever screen recording.

Hi Aaron,

On another note, I added Blender.exe as a specified program in the "Program Settings" tab to use maximum performance, rather than leaving it as a Global setting.

Yep, that's what it was: "Prefer Maximum Performance"! That was the only setting I changed just now, and sure enough, no more stuttering. So I guess the new "power saving" modes must have been added in the newer drivers and that's what broke it. Basically then, when I enabled the screen capture settings in my previous workaround, the GPU must have kicked into the "Prefer Maximum Performance" mode, which "indirectly" solved the stuttering.

Thanks so much, Daniel! Yes, that does work, however, I noticed the settings only take effect once Blender is closed and re-opened (I tried changing the settings one at a time with Blender open to no effect). And resetting NVIDIA control panel back to default does cause Blender to re-exhibit the issue (when closed and re-opened). I'd have to try those 5 different settings individually while opening and closing Blender each time to know which of those settings are directly affecting the issue.

In T49758#403740, @Bastien Montagne (mont29) wrote:

This is definitively an NVidia dirver bug, if with one version of driver everything is OK and the next it’s not… that’s called regression. We cannot fix their drivers for them.

It's very strange how enabling Sharing, Instant Replay, and Desktop Capture in NVIDIA GeForce Experience allows me to run Multisample x16 inside Blender without any glitching at 1440p... I just tested again to be sure. However, even if the original issue can't be fixed, this workaround does "solve" the problem. Thanks :-)

Just found the solution: The UV islands just needed more padding around them. Even though they looked clear, this mip map error would show up from a distance. :-)

My bad... just checked 2.77a and it has the same UV seams issue. Apparently someone had the same issue as me back in 2007, so I guess this problem's been around for awhile. Wonder if anyone found a workaround for something with an all white texture and a distant camera? Anyway, feel free to set the original report to solved, if you wish. The NVIDIA GeForce Experience workaround seems to be an adequate solution. No idea why things had changed though on the newer drivers... except maybe when they recently overhauled GeForce Experience they broke something.

Thanks Sergey! I tested it out in Blender 2.78 with all the NVIDIA settings off and at first the issue appeared to be fixed, but when I launched a project from hard drive directly, sure enough, the lag was still there.

I am setting this back to open, as NVIDIA claims this is a Blender-specific issue. The previous info I added about enabling Desktop Capture in GeForce Experience privacy control to "solve" the issue, and disabling live replay to make the issue even worse still applies. Obviously, something major changed between the way Blender responds to 359.00 and 373.06.

This appears to be an NVIDIA issue, as the problem goes away when: