[Development] Moving math3d classes from GUI to CORE

[Lars Knoll]

Hi,

After some thinking, I pretty much agree with Laszlo. QVectorND, QMatrix4x4 and most other classes in math3d are really tuned towards graphics, and thus make little sense in Qt Core. So +1 for keeping them where they are and in addition a +1 for deprecating QGenericMatrix.

But I think that in this case would make sense to add the QMatrix3x3 class now instead of returning a std::array. We could keep the class fairly minimal in 5.15 so that it in practice is not much more than a wrapper around float[3][3]. But we’d have the right type then and can add API for it as needed for Qt 6.

Cheers,
Lars

On 23 Jan 2020, at 13:53, Laszlo Agocs <laszlo.agocs at qt.io<mailto:laszlo.agocs at qt.io>> wrote:

Hi,

Regarding math3d:

It turns out that QGenericMatrix has no actual matrix operations. It is merely a dumb templated container, which probably exists only because someone did not like the idea of QMatrix4x4::normalMatrix() outputting into a plain float[9]. Therefore, instead of dumping stuff with limited usefulness to Core, we could do the following:

1. Leave QVectornD and QMatrix4x4 in gui/math3d as these are not meant to be used as generic math classes, they serve the needs of graphics.

2. Deprecate QGenericMatrix and the related from/to functions in QMatrix4x4 in 5.15, remove in 6.0. Deprecate QMatrix4x4::normalMatrix() as well.

3. Add an alternative for QMatrix4x4::normalMatrix() returning an std::array<float, 9> (this is good enough for now since the only use case I am aware of is to expose the result as a mat3 to a shader). In the long run we’ll probably introduce a proper 3x3 matrix class, but that is not necessarily the most urgent thing for 6.0.

4. Longer term, let's rather focus the energy on improving performance (via SSE, NEON) in math3d, as that would probably bring more benefits to Qt Quick and Quick 3D than spending effort on trying to get QtCore compete with existing linear algebra solutions out there.

Best regards,
Laszlo


From: Development <development-bounces at qt-project.org<mailto:development-bounces at qt-project.org>> On Behalf Of Konstantin Shegunov
Sent: Thursday, January 23, 2020 1:38 PM
To: Jaroslaw Kobus <Jaroslaw.Kobus at qt.io<mailto:Jaroslaw.Kobus at qt.io>>
Cc: development at qt-project.org<mailto:development at qt-project.org>
Subject: Re: [Development] Moving math3d classes from GUI to CORE

Hi.

On Thu, Jan 23, 2020 at 10:56 AM Jaroslaw Kobus <Jaroslaw.Kobus at qt.io<mailto:Jaroslaw.Kobus at qt.io>> wrote:
one of the tasks planned for Qt 6 is to move the math3D classes from QtGui to QtCore (https://bugreports.qt.io/browse/QTBUG-46653).

Why? My personal experience leads me to believe that the transformations and such aren't really suited for general-purpose work (i.e. gui unrelated), so I really don't see the point of going through the motions. This is what we also advise people in the forums - if you want to do math on vectors (unrelated to the painting), do it manually/pull a dep or w/e.

These may be interesting for you to take a look at:
https://bugreports.qt.io/browse/QTBUG-75146, which triggered:
https://bugreports.qt.io/browse/QTBUG-75879
leading to:
https://codereview.qt-project.org/c/qt/qtbase/+/261770 and
https://codereview.qt-project.org/c/qt/qtbase/+/261715
none of which seem to be possible, or wanted.

1. QMatrix4x4 class (to be moved into Core) uses QTransform class (which is currently a part of Gui lib, inside paining dir):
2. Old QMatrix class, which is to be ultimately deprecated in Qt 5.15, is a field member of:

I'll pass here, I don't have an opinion on that.

3. QMatrix inside QVariant / QMetaType. If we are going to remove QMatrix type in Qt 6, we need to remove it from QMetaType::Type enum (current value = 79). Then we create a gap at position 79. We may adjust the values for other types (like instead of 80 for QTransform we move it to 79, and so on). However, I wonder whether it is going to work in cases like data streaming (e.g. someone stored the variant using Qt 5.15 and now he want to read it in Qt 6). Or should we just leave the gap at 79?

I'd say leave the gap, seems more prudent. My concern you spelled explicitly already - if indeed someone uses a stream that comes from Qt 5.x but is read in Qt 6.x then reordering the types means breaking the stream for no obvious reason.

4. Where to place math3d classes? Currently they are in gui/math3d. Should they go to corelib/math3d, or should they be added into some already existing dir, like corelib/tools?

I think it's best to leave them in the gui module.

Kind regards,
Konstantin.
_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
https://lists.qt-project.org/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200123/cd091a52/attachment-0001.html>