Returns true if the symbol layer rendering can cause visible
artifacts across a single feature when the feature is rendered
as a series of adjacent map tiles each containing a portion
of the feature's geometry.
This depends on the symbol layer derived class itself - eg
a simple solid color fill won't show any artifacts, but a shapeburst
fill WILL.
check if a node has already been determined to evaluate to a static,
precalculated value, and if so, use this value for the node instead
of attempting to compile the actual contents of the node itself
If we are certain that a node is static and will never change,
the this potentially allows us to short-cut a large part of the
filter expressions content. We already use this short-cut when
evaluating expressions on the QGIS side since years, and its
proven to be stable and reliable. By respecting this during
expression compilation we can offer a huge speed up to certain
filter expressions, especially those which utilise QGIS variables
which are known to be static (such as atlas variables, map scales,
etc). Previously ANY use of a qgis variable would always cause
expression compilation to fail and require a full set of feature
fetching from the provider.
(Resulted in orders of magnitude faster atlas export for a complex
atlas.)
when a script calls Processing.initialize() if they are not
already loaded
This means the following ugly code can be avoided:
Processing.initialize()
QgsApplication.processingRegistry().addProvider(QgsNativeAlgorithms(QgsApplication.processingRegistry()))
QgsApplication.processingRegistry().addProvider(Qgs3DAlgorithms(QgsApplication.processingRegistry()))
and instead the call to Processing.initialize() is sufficient to load
ALL providers
Fixes#41310
field) when the attribute form is opened.
This is incredibly expensive, yet only required in a very very small
corner case (field is from a joined layer without the upsert on edit
capabilities).
Refine logic to avoid the scan wherever we can.
Fixes#41366Fixes#36863
