The old behaviour was always to just redraw the layer, without
refreshing data. This was by design, as the feature was originally
developed to allow animated layers which needed to be regular,
quickly redrawn.
But there's also a use case for automatically refetching layer
data on a regular interval too. So now we expose a choice
of mode for the automatic refresh for users to decided which
is appropriate for their requirements.
The options are:
- "Reload Data": The layer will be completely refreshed. Any cached
data will be discarded and refetched from the provider. This mode
may result in slower map refreshes.
- "Redraw Layer Only": This mode is useful for animation or when
the layer's style will be updated at regular intervals. Canvas
updates are deferred in order to avoid refreshing multiple times
if more than one layer has an auto update interval set.
The changes are all wrapped up in a new reusable widget, so that
we can easily expose this setting for non vector/raster layers
if we want to in future.
Fixes https://github.com/qgis/QGIS/issues/39830
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.
force the layer to be rasterised
There's no benefit in exporting these layers as a bunch of triangular
images which are pieced together, that adds a lot of extra content to
the exports and results in files which can be extremely slow to open
and render in other viewers.
We currently offer three renderer choices:
- Textured (default). Loads the texture image and paints the mesh using
these textures
- Texture color. Uses the center point color for rendering each mesh
triangle. Gives a clear visual overview of the mesh structure while
also providing some context via the texture color
- Mesh. Renders the scene's mesh using a fill symbol
alter the handling of symbol layers
These differ from Qgis::SymbolLayerFlag in that
Qgis::SymbolLayerFlag flags are used to reflect the inbuilt properties
of a symbol layer type, whereas Qgis::SymbolLayerUserFlag are optional,
user controlled flags which can be toggled for a symbol layer.
Add a flag `DisableSelectionRecoloring` which can be set for
symbol layers which prevents the layer from being recolored to
the render context selection color even when the feature
being rendered is selected
This provides a mechanism for an individual symbol layer to
avoid the forced recolor of selected features.
This is the base API interface classes for creation of custom
2d or 3d map controllers, and registering them in a common
QgsInputControllerManager singleton class.
the text annotation should handle map rotation
Previously, text annotations just ignore map rotation, which
matches how regular map labels are handled. But this is not
desirable for some point text annotations, where it can
be considered a bug that the item ignores the map rotation (eg
when a text annotation has been placed to align with a feature
on the map, such as a road)
There's no one "correct" behaviour here, so add a new
combo box widget in the annotation point text settings with
options for
"Ignore Map Rotation"
"Rotate With Map"
so that users can pick the desired behavior for their annotations
always be used for the layer (as opposed to any previously
stored matrix sets)
For some vector tile data providers this is more appropriate --
specifically for those with tilemap information where we MUST
ensure that the tilemap matches the data source or missing
tiles may be present. (If we store the matrix set information
in projects then loading older projects may mean that a stored
tilemap is out-of-sync with the actual data source's current
tilemap).
This allows us to correctly handle "indexed" vector tile sets,
where higher zoom level tiles may be missing where a lower
zoom level tile is deemed to have sufficient detail for higher
zoom levels.
This container always lays out child widgets in a horizontal
row, where the number of columns is automatically determined
by the number of child widgets.
It's useful for creation of compact forms, where no space will
be wasted by assigning extraneous horizontal width to widgets
where the expected values will always be short.
Eg: creating 3 rows with 3, 2, 1 child widgets respectively
results in the layout:
Attr 1: [...] Attr 2: [...] Attr 3: [...]
Attr 4: [..........] Attr 5: [..........]
Attr 6: [...............................]
Without the option of row containers then the all horizontal
rows will have the same number of columns, eg:
Attr 1: [...] Attr 2: [...] Attr 3: [...]
Attr 4: [...] Attr 5: [...] Attr 6: [...]
(leaving insufficient horizontal length for attributes 4-6), or
Attr 1: [..........] Attr 2: [..........]
Attr 2: [..........] Attr 3: [..........]
Attr 4: [..........] Attr 5: [..........]
Attr 6: [..........]
(resulting in wasted horizontal space next to attribute 6, and
an extra row taking up vertical space)
Sponsored by NIWA
QgsAbstractDatabaseProviderConnection
When implemented by providers, will provide a method for
permanently setting field aliases/comments within a
database
Here we have no choice but to create a new Capability2
enum, as the original Capability has now consumed the
entire range of values for data types permitted by QFlag
