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.
stored in a single place, and that we always use the default
value when its not overwise set
This has two benefits:
1. The user doesn't see confusing "0" values for radius/length etc,
which are silently treated as some other fixed value when rendering
2. The default values are correctly accounted for when calculating
the layer's AABB, otherwise we end up with a flat AABB by
default
This method will be used where multiple calls to `qgsDoubleNear(x1, y1, eps) &&
qgsDoubleNear(x2, y2, eps) && ... && qgsDoubleNear(xn, yn, eps)` are possible.
