Don't use QTime::elapsed() on windows to query for the actual time.

It seems that the time spent between the execution of QTime::start()
and QTime::elapsed() can be higher than what QTime::elapsed() sometimes
reports. (To put it differently, QTime::elapsed() was sometimes
returning a time that was *less* than the actual time spent.)

Note that this is *not* a bug on Windows, since GetLocalTime explicitly
mentions that we should not use local system times to to relative
comparisions (this is what elapsed() currently do).
This is also partly reflected by the documentation of QTime::elapsed(),
where it says that the result of elapsed() is undefined if the clock
setting has been changed.
Due to the fact mentioned in the above paragraph this is also a
potential problem on other platforms (at least Linux and Mac).
However, these platforms do not suffer from the immediate problem we
observed on windows (that QTime::elapsed() could return a too small
value), so this commit only fixes the problem on Windows (it now uses
GetTickCount instead of QTime). For the other platforms the behaviour
should be unchanged, since we still use QTime.

This was found by running the QPauseAnimation autotest, where some
tests were unstable (and failed). However, it did not fail on all
windows systems. (Luckilly it failed on my Win 7 system)

Reviewed-by: Leo

0 files changed, 0 insertions, 0 deletions