[Development] Moving math3d classes from GUI to CORE

[Jaroslaw Kobus]

Resending it to development list, it was the original intention, but it went to another list.

BR

Jarek

________________________________________
From: Jaroslaw Kobus
Sent: Tuesday, January 21, 2020 1:33 PM
To: Qt Development
Subject: Moving math3d classes from GUI to CORE

Hi All,

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).
I've done some reconnaissance and detected some issues that need to be decided before the task is done:

1. QMatrix4x4 class (to be moved into Core) uses QTransform class (which is currently a part of Gui lib, inside paining dir):

QTransform QMatrix4x4::toTransform() const;

We may deprecate this method and introduce e.g.:

static QTransform QTransform::fromMatrix(const QMatrix4x4 &matrix);

Or we may consider moving QTransform class together with other math3d classes. IMO this would be a nice way to go, since QTransform is only a data class (+ some useful methods) which could be potentially used outside of GUI scope, too. However, QTransform::map() methods use classes like: QPainterPath, QPolygon and QRegion. So in turn, we would meet the similar problem again - what to do with them? We could either move these methods outside of QTransform, like:

QPolygon QTransform::map(const QPolygon &a) const; -> QPolygon QPolygon::map(const QTransform &transform) const;

The other option would be to move these classes together with QTransform into the same common place. This would probably be too difficult due to the fact, that these classes are not just pure data holders with some access / mutators / transform methods, but looks like they are quite deeply integrated into GUI lib.

2. Old QMatrix class, which is to be ultimately deprecated in Qt 5.15, is a field member of:

a) QTransform::affine - matrix is a private field of a public header. Thus the options for Qt 6 are:
- replace it with a vector of qreal
- replace it with a QMatrix3x3 or QGenericMatrix of qreal
- provide the d-pointer in the header and move all private data into the private implementation, as with many other data classes in Qt. However, this class is probably used in many time critical contexts, like graphics rendering, where performance is quite important, so the question is: would d-pointer be acceptable for this class? I've found a benchmark test for qtransform inside Qt, so I could compare the results from before and after the change. Should other things be taken into account here?
- other options...?

b) QStyleOptionGraphicsItem::matrix - it's a public field of QMatrix type, already obsoleted some time ago. Also, it looks like there are more obsoleted fields in QStyleOptionX classes, e.g. QStyleOptionGraphicsItem::levelOfDetail. So, should they be direclty removed in Qt 6, or do we need to provide a hack like in QStyleOptionTabV4? Maybe QStyleOptionX classes and their obsoleted fields are the subject for another story...

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?

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?

Any comments are very welcome!

Thanks and regards

Jarek