[Development] Proposing reversal of the Math3D qreal->float change

[Sean Harmer]

On 11/09/2012 13:34, Thiago Macieira wrote:
> 51d40d7e9bdfc63c5109aef5b732aa2ba10f985a changed the types of the Math3D
> classes from qreal to float. That's a major source- and behaviour-incompatible
> change, done after the beta, with no mention in the changelog or discussion on
> this mailing list (unless it's an old discussion and it's only now made it
> through).

Yes it was unfortunate this change missed the beta. I would propose to 
keep the change in and fix the uses of these classes. Many of the 
failures seen in Qt3D were due to that module using qreal when again 
float would really be a better choice and the work arounds put in place 
to avoid comparing doubles that only have single-precision (see below) 
in qFuzzyCompare.

The change was discussed with Gunnar on irc who agreed that the API of 
the math3d classes was just plain broken due to the QVector*D classes 
previously using qreal in the API but using float as internal storage 
which is inconsistent. The QQuaternion and QMatrix4x4 classes were using 
qreals both in the API and internal storage which was at least 
self-consistent but inconsistent with the QVector*D classes.

I would argue that such mixing of qreal and float within and between 
these classes leads to even worse bugs that are harder to track down as 
using a QMatrix4x4 you think you have double precision on the desktop 
but as soon as you multiplied it by a QVector4D you actually get reduced 
to single precision because that is all that QVector*D supported 
internally. This means that when accessing the components of a 
transformed vector, although you get back a double (on the desktop) the 
double actually only has contents that are single-precision. Horrible.
>
> Note that half of the issues we've found so far are due to test failures after
> the change in precision. That means we're introducing subtle and hard-to-find
> behaviour incompatibilities.
The failures are being picked up by the unit tests, many of which are 
flawed anyway as they are testing floating point values for equality.
>
> I propose we revert it.
I propose we (I) fix the affected classes in QtMultimedia and Qt3D. I'm 
away on business this week but I will make a start asap.

Cheers,

Sean