Quote Originally Posted by zir_blazer View Post
Issues like that would probabily affect both SLI and Crossfire in the same way. Yet Crossfire has some serious issues that SLI doesn't have, so its the Crossfire implementation the one that is to blame considering that SLI scales quite good.
They can as seen in some HT vs non-HT results, however "can" is not "always".

There is always, everywhere, people complaining about certain graphic glitchs, slowdowns, shuttering, whatever. What you see is what matters, end users usually doesn't really care about the inner workings of it for as long as it works properly. This technique to focus on the graphic output is what will help the most to properly see and identify all those issues, as with it you don't depend on a person perception to detect them (Not everyone notices), and get into a more scientific, exact method.
Why is this method the most correct? Why cant another method which is not using visual perception work as well or better, given that it may actually also include this method as well as others? Why is one method which performs only one test better than multiple methods which test multiple issues?

You've basically jumped off an assumption cliff with your line of reasoning..

Once you know that there is an issue somewhere, then you could use even more tools to properly identify what happens at the moment that the glitch/shutter occurs, to know what is the actual cause (Hardware, OS, Drivers, whatever), and try to fix it.
I'm very optimistic that with ths method, it will be posible to do before-and-after comparisions so you can see if an specific option (Like VSync), a new Drivers version, Software patch, or anything else, has a positive or negative impact. So it will be trackeable if there are actual improvements.
So you cant use other methods in your previous statement but then you suddenly can in the next? Hmm.. seems you've cliff jumped before if you're going to bring a parachute