Here we have to break with our previous approach of treating
null variants (NULL in Python) different to invalid qvariants (None in
Python)
There's simply NO way to construct null variants in PyQt6 -- they
are ALWAYS mapped across to Py_None.
This isn't as big a deal as it sounds, we already made the decision
in c++ code to move to invalid variants in favour of null variants.
Note that we STILL need the custom sip code here and can't rely
on base PyQt6 null variant conversion, as that relies on
QVariant::isNull when we must use QgsVariantUtils::isNull so
that the underlying type is correctly checked for null values
on Qt 6 builds.
QVariant::Type does not exist in PyQt6 as its been deprecated
and replaced with QMetaType::Type.
In order to avoid breaking PyQGIS API, we don't want to change
all our functions to use QMetaType::Type instead of QVariant::Type
(that can wait till QGIS 4.0). So instead we leave the c++/Qt 5
signatures as QVariant::Type, but accept QMetaType::Type values
for these functions under Qt 6 builds.
While QVariant::Type can be directly static_cast to QMetaType::Type,
the reverse is not true and many QMetaType::Type values don't
have exact counterparts in QVariant::Type.
So we use the logic:
- If no conversion is possible, QVariant::UserType will be returned.
Note that we don't use QVariant::Invalid, as the value DOES have
a type, it's just one which needs special handling (just like user
types do)
- Some conversions are lossy, in that the QVariant::Type cannot
represent the full range of values possible in QMetaType::Type.
In these cases the returned type will be an "expanded" type
capable of storing the full range of values possible in the
original type. Eg we map QMetaType::Type::Float to QVariant::Type::Double
QgsVariantUtils::variantTypeToMetaType is included for clarity/
completeness/future proof-ness, even though it currently can
be handled with just a simple static cast.
The comparisons among QGIS were conducted on coordinates using a fixed epsilon:
specifically, 1e-8 for QgsPoint and the default value for qgsDoubleNear: 4 *
DBL_EPSILON.
Initially, I've standardized its use to 1e-8 universally; it's already
significantly adequate for our Cartesian cases (1e-3 should suffice for many),
potentially fitting just right for geographical contexts.
Furthermore, in response to precision concerns, we're using the fuzzyEqual
and fuzzyDistanceEqual methods. These methods enable users/developers to
compare geometries more easily and with a given precision.
The API remains intact as operator==/equals() have been shifted into fuzzyEqual
(with an epsilon of 1e-8).
To consolidate the code between fuzzyEqual and fuzzyDistanceEqual, helper
functions, fuzzyHelpers, have been introduced following the logic of the
respective segments to be executed.
As for the sqrDistance and Distance 2D functions, this adds functions for 3D.
To maintain the lowest level, the specific case where a Z could be NaN
is not handled.
It is left to the responsibility of other methods using these functions.
The backward compatibility code is very expensive, as it triggers
a huge number of QSetting object creation and destruction.
We only need to perform this for settings which have changed,
so add API to flag changed settings and only perform backward
migration of changed settings.
This dramatically improves QgsApplication shutdown time (cuts
1.5 seconds off shutdown on a release build!!)
Populating the style library from the database can be a time
consuming process, especially if a user has many symbols
present in their library.
But for many standalone scripts, and for qgis_process, the
style database may not be required.
Let's defer initialization of it until it's actually required,
saving the startup cost in qgis_process and 3rd party scripts.
On my system with a style database containing ~700 items this
cuts down qgis_process startup times by around 25%
This adds a mechanism where flushes of QgsSettings to the underlying
ini storage file can be temporarily suspended. It is intended for
code paths where many settings entries are consecutively read/written,
to avoid the very expensive cost of constructing and destructing
multiple QgsSettings objects for each in turn.
When QgsSettings::holdFlush() is called, then a temporary thread local
QgsSettings object will be created and ALL access to settings entries
will use this same object (preventing flushing of it to ini files).
An accompanying QgsSettings::releaseFlush() call MUST be made from
the same thread to destroy the thread local QgsSettings, flush it
to disk, and resume normal operation.
This helps avoid the VERY costly backward migration of settings,
and cuts the run time for qgis_process commands like `qgis_process list`
by at least half (and considerably more in common setups).
QCA and SSL certificate initialize can be costly -- so defer
startup of authentication framework until it is actually required.
This has no effect on QGIS desktop, as the news feed request
and other startup network requests will immediately trigger
an initialization of the framework. The use case here is improving
the core application startup time to benefit non-app based clients,
eg. qgis_process.
This method will be used where multiple calls to `qgsDoubleNear(x1, y1, eps) &&
qgsDoubleNear(x2, y2, eps) && ... && qgsDoubleNear(xn, yn, eps)` are possible.
