renderer operations
This follow a similar pattern as how labeling results could be collected
after a map render job, but generalises the API so that it can be
used for storing details of rendered items of any type.
It's currently used for storing details of rendered annotation items,
so that map tools can retrieve details of annotation items visible
in the canvas in an optimised way.
Because some annotation items have scale dependent bounding boxes,
we can only index items which have a fixed bounding box. Other
item bounds need to be dynamically determined based on a specific
render context. So rework the annotation layer index handling
to only index appropriate items and store other items in a non-indexed
item set.
This isn't ideal, because it means we need to clone ALL non-indexed
items upfront whenever we render an annotation layer (it's too expensive
to calculate their actual bounding box and selectively clone them,
as it's a process which blocks the main thread).
Hopefully we can think of an alternative approach to this down
the line so that we DO have some form of spatial index for scale
dependent items, unlocking better performance for annotation layers
with 10,000s of items. But we'll ignore that situation for now ;)
to annotation layers to reflect that while these are editable
users are not able to toggle edits on them (they are ALWAYS
editable!)
Note that we can't use the existing QgsMapLayer::LayerFlag enum here,
as that has a different meaning (flags which are set by users
at runtime)
- Add enums to qgis.h instead of qgscoreenums, so that they belong to
a Qgis namespace
- Split up the various symbol headers into multiple files so that we
can fine-tune their inclusion and forward declare more readily, speeding
up recompilation
- Move QgsSymbol enums to qgis
All the logic for rendering non-opaque layers is handled in a layer
type agnostic way already, so this just allows the existing handling
to be used for mesh/point cloud/vector tile/etc layers also
work correctly with curved geometry types, and tweak some API naming
accordingly
There's no need to be restrictive and only require linear geometries
for these items!
Adds a new visitor pattern API for creation of visitors which visit
all the style entities (symbols, color ramps, text formats, and
label styles) associated with different objects. Can be used on a
renderer, map layer, or project wide level.
E.g. on a project wide level, allows collection of ALL the style
symbols/color ramps/text settings inside a project, including those
in layouts or annotations!
Previously, annotation size and position always used pixel units. This
did not work well when exporting layouts, resulting in tiny annotations
(it also caused issues when moving projects between hidpi/non hidpi
displays).
Instead, use millimeters for annotation size and position so that the
appearance is consistent across displays and works correctly in layout
exports.
Add lots of unit tests covering this.
Fixes#18373
