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.
map layer renderers
These renderers can then use the layer rendering time for the previous
map render job to refine their logic regarding when its appropriate
to start compositing the layer render
flattening onto a temporary image to the QgsMapLayerRenderer subclasses
This avoids the generic QgsMapRendererJob class from having hardcoded
layer type dependent behavior, and instead moves that layer-type specific
logic to the subclasses designed for that particular layer
For the c++ api dox this expands to "\c nullptr" (the
\c directive indicates a code literal value), and for sipify/Python
it expands to ``None`` (`` is sphinx annotation for literal values)
Makes for nicer dox for both c++ and Python!
