Re: [Development] Proposing reversal of the Math3D qreal-float change
No, it changed the expectations. People develop with qreal as double, and than magic things happen on ARM. My proposal is, that we change most interfaces to double, there it really costs, we switch to float. Otherwise we break our interfaces. For example, a application is saving world coordiantes in qreal(QPointF), this is fine with qreal as double, but you get in trouble if qreal is float(I was told so). So, this application can only run cross platform, if we stick to our interface and don't change it magically. Maybe we should introduce Q*F and Q*D like QRectF and QRectD? But the first step would be in my opinion the removal of qreal. It should be really KISS! From: ext Romain Pokrzywka [romain.pokrzy...@kdab.com] Sent: Thursday, September 13, 2012 2:10 AM To: development@qt-project.org Cc: Bubke Marco (Nokia-MP/Berlin); Knoll Lars (Nokia-MP/Oslo); andre.poen...@mathematik.tu-chemnitz.de; sean.har...@kdab.com Subject: Re: [Development] Proposing reversal of the Math3D qreal-float change On Wednesday, September 12, 2012 09:20:15 AM marco.bu...@nokia.com wrote: On Sep 12, 2012, at 12:27 AM, ext André Pönitz andre.poen...@mathematik.tu- chemnitz.de wrote: Version (a) means the current mess will go on. but it has the distict charme of (a.1) not breaking anyones existing code and (a.2) sticking to feature freeze rules. If somebody porting his app to ARM he will be surprised, because we change qreal to float. Sorry, this is cross platform magic. Actually change qreal explicitly to double is much better, because it is explicit. No this won't change anything, because qreal is already float on ARM platforms. I would opt for a explicit removal of qreal and exchange it with double! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
On terça-feira, 11 de setembro de 2012 22.44.52, Sean Harmer wrote: On 11/09/2012 22:39, Thiago Macieira wrote: On terça-feira, 11 de setembro de 2012 22.34.50, Sean Harmer wrote: 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. Qt3D is now passing. Yes it is passing. I will prepare a patch to remove the usage of qreal and see if the maintainer of that module agrees with it or not and take it from there. I'll correct the compilation errors for QtMultimedia, but not the tests. If tests show failures, we'll wait for you or someone else. OK, thank you. I'll do my best to address any failures in a timely manner. QtMultimedia compiled and passed the tests. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
On 09/13/2012 11:27 AM, marco.bu...@nokia.com wrote: [...] Q*F and Q*D like QRectF and QRectD? But the first step would be in my opinion the removal of qreal. It should be really KISS! OTOH, having a typedef which you can change to be either float or double according to your precision needs (and hardware possibilities) can be quite handy. Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
On Wednesday 12. September 2012 09.10.52 ext lars.kn...@nokia.com wrote: On Sep 12, 2012, at 12:27 AM, ext André Pönitz andre.poen...@mathematik.tu- chemnitz.de wrote: On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote: On 11/09/2012 13:34, Thiago Macieira wrote: 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. I believe I mentioned that before. Anyway: I think there are (medium term) only two acceptable solutions, none of them perfect: (a) keep everything as it is (or, rather, was) (b) have fully functional real/double verticals (c) Turn qreal into a double everywhere I would love to kill qreal but... please go for (a). The discussion was already finished once with conclusion that we should not do anything about it for Qt5. Let's stick to the decision. The feature freeze was in February. It is time to release not to do major changes. Cheers, Jędrek ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
On 13 September 2012 09:39, Jedrzej Nowacki jedrzej.nowa...@nokia.com wrote: I would love to kill qreal but... please go for (a). The discussion was already finished once with conclusion that we should not do anything about it for Qt5. Let's stick to the decision. The feature freeze was in February. It is time to release not to do major changes. How about at least unifying the internal storages to qreal instead of having QVector* using floats internally and qreals in the API? -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
On Wed, Sep 12, 2012 at 07:10:52AM +, lars.kn...@nokia.com wrote: On Sep 12, 2012, at 12:27 AM, ext André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote: On 11/09/2012 13:34, Thiago Macieira wrote: 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. I believe I mentioned that before. Anyway: I think there are (medium term) only two acceptable solutions, none of them perfect: (a) keep everything as it is (or, rather, was) (b) have fully functional real/double verticals (c) Turn qreal into a double everywhere Not sure this would be acceptable to everyone, but it would be fine with me _personally_. The case I absolutely want to avoid is turning anything that was a double into single precision as this can render existing applications useless. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
On Thursday, September 13, 2012 07:14:50 AM lars.kn...@nokia.com wrote: On Sep 13, 2012, at 2:07 AM, ext Romain Pokrzywka romain.pokrzy...@kdab.com wrote: On Wednesday, September 12, 2012 07:10:52 AM lars.kn...@nokia.com wrote: On Sep 12, 2012, at 12:27 AM, ext André Pönitz andre.poen...@mathematik.tu- chemnitz.de wrote: On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote: On 11/09/2012 13:34, Thiago Macieira wrote: 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. I believe I mentioned that before. Anyway: I think there are (medium term) only two acceptable solutions, none of them perfect: (a) keep everything as it is (or, rather, was) (b) have fully functional real/double verticals (c) Turn qreal into a double everywhere This was rejected before by some, because it might make things slower on ARM, but would have the advantage that it's fully source compatible with Qt 4, solves the mess and would allow us to introduce floating point types where required later. Only minuses I can see are (c1) the names of QXxxF classes which are double and not float based (c2) possibly slower execution on ARM (c3) Somewhat higher memory consumption on ARM (c1) is not easily fixed. But (c2) seems to be less of an issue these days. At least for the Cortex A9 ARM claims very good double precision support. Older CPUs also have some support through VFPv2/3. (c3) should also become less and less of an issue moving forward. So to bring this up again: How about turning qreal into a typedef for double on all platforms and remove the mess this way? Whereever we need (or want to use) floats, let's use them explicitly. I think the statements might make things slower on ARM and seems to be less of an issue these days are a little misleading and too optimistic. From my own experience, using double on ARM has a serious impact on performance at many levels: data size, code generation, and even FPU options. Indeed, from what I've read it seems like the Cortex-A9 is significantly closing the gap between float and double (although not eliminating it), but's it's really the only platform that does. [1] True, but more and more embedded systems will start using that platform. My main proposal is that the default (and supported) build of Qt on ARM uses doubles for qreal. If we keep the typedef, you could still typedef it to use float at your own risk :) True, that would be a good enough solution, e.g. as an option to configure Every other platform, Cortex-A8 and previous ARM architectures, and even Intel Atom, will suffer badly from switching from floats to doubles, even though they have VFP. This is mainly due to the crappy VFP abilities in those platforms, combined with the Cortex-A8 allowing use of the NEON co-processor as the FPU, with massive performance improvements over VFP, but only available for floats. [2] And it gets even worse when using -mfloat-abi=softfp. [3] Yes, but softfp doesn't make sense with Qt Quick 2 anyway. Now, considering that most usage of Qt on embedded platforms is either through QGraphicsView or Qt Quick (1 and 2), both of them relying heavily on floating point calculations (coordinate systems, painting with AA...), this is definitely a decision with a potentially serious impact on most embedded platforms. One solution here is to explicitly use floats internally in Qt wherever possible and where it's critical to performance. One may still argue that Qt5 should be targeting the latest and future platforms instead of legacy and current ones. Fair enough. But I think the consequences should be stressed more. Some extensive benchmarking would be nice too, before deciding on one solution against the other. As said above: It's about the default build that the Qt Project tests and supports. We can keep the option of forcing qreal to float at least for now or until we've proven that the performance impact is acceptable. Yep, I'm happy with that :) Thx, Romain Cheers, Lars [1] http://www.360doc.com/content/12/0806/14/350555_228637047.shtml [2] http://processors.wiki.ti.com/index.php/Cortex_A8#Neon_and_VFP_both_suppor t_floating_point.2C_which_should_I_use.3F [3] http://wiki.debian.org/ArmHardFloatPort/VfpComparison Regards, Romain Cheers, Lars Version (a) means the current mess will go on. but it has the distict charme of (a.1) not breaking anyones existing code and (a.2) sticking to feature freeze rules. Version (b) is somewhat closer to a proper solution, but fails (a.1) and (a.2). It has also the disadvantage of requiring real work, and therefore to tie up resources. Even with my usual let's break feature freeze if the feature is cool enough hat on, I am tempted to lean
Re: [Development] Proposing reversal of the Math3D qreal-float change
On Sep 12, 2012, at 12:27 AM, ext André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote: On 11/09/2012 13:34, Thiago Macieira wrote: 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. I believe I mentioned that before. Anyway: I think there are (medium term) only two acceptable solutions, none of them perfect: (a) keep everything as it is (or, rather, was) (b) have fully functional real/double verticals (c) Turn qreal into a double everywhere This was rejected before by some, because it might make things slower on ARM, but would have the advantage that it's fully source compatible with Qt 4, solves the mess and would allow us to introduce floating point types where required later. Only minuses I can see are (c1) the names of QXxxF classes which are double and not float based (c2) possibly slower execution on ARM (c3) Somewhat higher memory consumption on ARM (c1) is not easily fixed. But (c2) seems to be less of an issue these days. At least for the Cortex A9 ARM claims very good double precision support. Older CPUs also have some support through VFPv2/3. (c3) should also become less and less of an issue moving forward. So to bring this up again: How about turning qreal into a typedef for double on all platforms and remove the mess this way? Whereever we need (or want to use) floats, let's use them explicitly. Cheers, Lars Version (a) means the current mess will go on. but it has the distict charme of (a.1) not breaking anyones existing code and (a.2) sticking to feature freeze rules. Version (b) is somewhat closer to a proper solution, but fails (a.1) and (a.2). It has also the disadvantage of requiring real work, and therefore to tie up resources. Even with my usual let's break feature freeze if the feature is cool enough hat on, I am tempted to lean towards (a). We are late in the game, and there are one or two rather essential things to be done for Qt 5. Having applications lock up regularly does not exactly sound like a strong sell to me. And while partial and/or extremly slow window updates might give that warm and cosy sense of being back in Qt 2.1 times to some, I have ths nagging feeling that not everyone out there will appreciate it. So, please, make the things that were there work again, and do not open up new construction sites. And yes, that may mean postpone stuff to Qt 6 (or maybe convincing the Chief in a year or two that having a QT_NO_COMPATIBILITY would be a feasible approach) Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
On Sep 12, 2012, at 12:27 AM, ext André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: Version (a) means the current mess will go on. but it has the distict charme of (a.1) not breaking anyones existing code and (a.2) sticking to feature freeze rules. If somebody porting his app to ARM he will be surprised, because we change qreal to float. Sorry, this is cross platform magic. Actually change qreal explicitly to double is much better, because it is explicit. I would opt for a explicit removal of qreal and exchange it with double! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
On quarta-feira, 12 de setembro de 2012 07.10.52, lars.kn...@nokia.com wrote: Only minuses I can see are (c1) the names of QXxxF classes which are double and not float based (c2) possibly slower execution on ARM (c3) Somewhat higher memory consumption on ARM (c1) is not easily fixed. But (c2) seems to be less of an issue these days. At least for the Cortex A9 ARM claims very good double precision support. Older CPUs also have some support through VFPv2/3. (c3) should also become less and less of an issue moving forward. So to bring this up again: How about turning qreal into a typedef for double on all platforms and remove the mess this way? Whereever we need (or want to use) floats, let's use them explicitly. Please note that this is an orthogonal decision to the problem I posted. The Math3D classes are no longer using qreal now, they're using float directly. That's what's causing the source- and behaviour-incompatibility. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
On Wednesday, September 12, 2012 09:20:15 AM marco.bu...@nokia.com wrote: On Sep 12, 2012, at 12:27 AM, ext André Pönitz andre.poen...@mathematik.tu- chemnitz.de wrote: Version (a) means the current mess will go on. but it has the distict charme of (a.1) not breaking anyones existing code and (a.2) sticking to feature freeze rules. If somebody porting his app to ARM he will be surprised, because we change qreal to float. Sorry, this is cross platform magic. Actually change qreal explicitly to double is much better, because it is explicit. No this won't change anything, because qreal is already float on ARM platforms. I would opt for a explicit removal of qreal and exchange it with double! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Proposing reversal of the Math3D qreal-float change
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). 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. I propose we revert it. Build logs with failures relating to that change: - QtMultimedia: still broken http://testresults.qt- project.org/ci/QtMultimedia_master_Integration/build_00521/linux-g%2B%2B_no- widgets_Ubuntu_12.04_x64/log.txt.gz - Qt3D: finally fixed, after 8 attempts http://testresults.qt- project.org/ci/Qt3D_master_Integration/build_00289/linux-g%2B%2B_shadow- build_Ubuntu_11.10_x86/log.txt.gz http://testresults.qt- project.org/ci/Qt3D_master_Integration/build_00287/linux- g%2B%2B-32_Ubuntu_10.04_x86/log.txt.gz http://testresults.qt- project.org/ci/Qt3D_master_Integration/build_00285/linux- g%2B%2B-32_Ubuntu_10.04_x86/log.txt.gz http://testresults.qt- project.org/ci/Qt3D_master_Integration/build_00284/linux-g%2B%2B_developer- build_qtnamespace_qtlibinfix_Ubuntu_11.10_x64/log.txt.gz http://testresults.qt- project.org/ci/Qt3D_master_Integration/build_00283/linux- g%2B%2B-32_Ubuntu_10.04_x86/log.txt.gz -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
But than we would be not have the same behaviour, if qreal is float or double. Actually I changed every code in the qml designer explicitly to double or float. It would be really nice, if the Qt classes would be has a float and a double implementation. From my perspective qreal is breaking the cross plattform promise! regards, Marco From: development-bounces+marco.bubke=nokia@qt-project.org [development-bounces+marco.bubke=nokia@qt-project.org] on behalf of ext Thiago Macieira [thiago.macie...@intel.com] Sent: Tuesday, September 11, 2012 2:34 PM To: development@qt-project.org Subject: [Development] Proposing reversal of the Math3D qreal-float change 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). 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. I propose we revert it. Build logs with failures relating to that change: - QtMultimedia: still broken http://testresults.qt- project.org/ci/QtMultimedia_master_Integration/build_00521/linux-g%2B%2B_no- widgets_Ubuntu_12.04_x64/log.txt.gz - Qt3D: finally fixed, after 8 attempts http://testresults.qt- project.org/ci/Qt3D_master_Integration/build_00289/linux-g%2B%2B_shadow- build_Ubuntu_11.10_x86/log.txt.gz http://testresults.qt- project.org/ci/Qt3D_master_Integration/build_00287/linux- g%2B%2B-32_Ubuntu_10.04_x86/log.txt.gz http://testresults.qt- project.org/ci/Qt3D_master_Integration/build_00285/linux- g%2B%2B-32_Ubuntu_10.04_x86/log.txt.gz http://testresults.qt- project.org/ci/Qt3D_master_Integration/build_00284/linux-g%2B%2B_developer- build_qtnamespace_qtlibinfix_Ubuntu_11.10_x64/log.txt.gz http://testresults.qt- project.org/ci/Qt3D_master_Integration/build_00283/linux- g%2B%2B-32_Ubuntu_10.04_x86/log.txt.gz -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
On terça-feira, 11 de setembro de 2012 12.46.56, marco.bu...@nokia.com wrote: But than we would be not have the same behaviour, if qreal is float or double. Actually I changed every code in the qml designer explicitly to double or float. It would be really nice, if the Qt classes would be has a float and a double implementation. From my perspective qreal is breaking the cross plattform promise! We discussed changing qreal to either of the types and we did not come to a conclusion. The best solution would be to provide the complex types in both formats and let the API decide which one is more suitable. For example, QtLocation would prefer to have double precision, but the OpenGL-related functionality might be satisfied with single precision. But doing that was source-incompatible. So we didn't change qreal. We only changed the Math3D classes, apparently because they're used with OpenGL only. The only problem is that no one had ever tested them with single precision while qreal is double, or in a platform where unit tests are run. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
On terça-feira, 11 de setembro de 2012 22.34.50, Sean Harmer wrote: 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. Qt3D is now passing. I'll correct the compilation errors for QtMultimedia, but not the tests. If tests show failures, we'll wait for you or someone else. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
On 11/09/2012 14:08, Thiago Macieira wrote: On terça-feira, 11 de setembro de 2012 12.46.56, marco.bu...@nokia.com wrote: But than we would be not have the same behaviour, if qreal is float or double. Actually I changed every code in the qml designer explicitly to double or float. It would be really nice, if the Qt classes would be has a float and a double implementation. From my perspective qreal is breaking the cross plattform promise! I agree. qreal should be avoided if you care for the error characteristics of your algorithms. We discussed changing qreal to either of the types and we did not come to a conclusion. The best solution would be to provide the complex types in both formats and let the API decide which one is more suitable. For example, QtLocation would prefer to have double precision, but the OpenGL-related functionality might be satisfied with single precision. Indeed, and QtLocation have in fact introduced their own double-precision equivalents for that purpose. Yes it would be nice to also have such classes in QtGui (or even QtCore but that is another dicsussion). But doing that was source-incompatible. So we didn't change qreal. We only changed the Math3D classes, apparently because they're used with OpenGL only. Usage with OpenGL is the intent of the math3d classes. Prior the change in question QOpenGLShaderProgram was even iterating over the contents of QMatrix4x4 and converting them to floats before passing them over as uniform variables to the shader program since OpenGL does not support doubles (at least until very recent versions of OpenGL) If it is decided that the math3d classes should be of use to more than OpenGL, then yes it would be good to see double-precision versions of these classes present too. If not then that is also fine as there are alternatives available (e.g. Eigen) which might be more suitable for serious number crunching anyway. The only problem is that no one had ever tested them with single precision while qreal is double, or in a platform where unit tests are run. Yes. So now we are seeing all those issues that have been invisible in Qt until now. As mentioned in my previous mail, I would strongly suggest fixing the issues rather than re-introducing the fundamentally broken API. Cheers, Sean ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing reversal of the Math3D qreal-float change
On Tue, Sep 11, 2012 at 10:34:50PM +0100, Sean Harmer wrote: On 11/09/2012 13:34, Thiago Macieira wrote: 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. I believe I mentioned that before. Anyway: I think there are (medium term) only two acceptable solutions, none of them perfect: (a) keep everything as it is (or, rather, was) (b) have fully functional real/double verticals Version (a) means the current mess will go on. but it has the distict charme of (a.1) not breaking anyones existing code and (a.2) sticking to feature freeze rules. Version (b) is somewhat closer to a proper solution, but fails (a.1) and (a.2). It has also the disadvantage of requiring real work, and therefore to tie up resources. Even with my usual let's break feature freeze if the feature is cool enough hat on, I am tempted to lean towards (a). We are late in the game, and there are one or two rather essential things to be done for Qt 5. Having applications lock up regularly does not exactly sound like a strong sell to me. And while partial and/or extremly slow window updates might give that warm and cosy sense of being back in Qt 2.1 times to some, I have ths nagging feeling that not everyone out there will appreciate it. So, please, make the things that were there work again, and do not open up new construction sites. And yes, that may mean postpone stuff to Qt 6 (or maybe convincing the Chief in a year or two that having a QT_NO_COMPATIBILITY would be a feasible approach) Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
