progress preview render results while drawing the layer, which
differ from the final layer render
The immediate use case here is for rendering tiled scene layers.
In order to generate the actual final render for these layers,
we need to first fetch ALL content for the render and then sort
the primitives by z value. But this means that the layer renders
can be extremely slow, with no visible changes on the map until
all the content fetching is complete. Not great user experience!
Instead, here we add the infrastructure so that a layer renderer
can get a temporary image to paint to for any partial renders.
This image gets used during map composition up until the layer
finally finishes rendering, at which time the layer's actual
destination image will be used for the composition.
This means that tiled scene renderers can now draw all tiles
(with unsorted primitives, and the artifacts which come with
that) as soon as we fetch each tile. This gives the user an
immediate visual reflection that the tiles are being fetched
and that how quickly (or slowly) that is happening. As soon
as we've got all tiles, the layer render will be immediately
switched to the version in which all content is rendered
in the correct z order.
As a bonus, we draw these temporary in progress renders
over any previously transformed cache version of the layer
available. So eg when you zoom in, you'll get a zoomed in pixelated
version of the last render which gets progressively drawn
over with each tile as it is fetched.
This same API could be used in future eg with point cloud
rendering when points are being sorted by z value to give
timely visual feedback.
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!
