they collide with an obstacle feature of greater weight when compared
to the label's priority
Previously, obstacle weight was used ONLY to rank a features' label
candidates relative to each other, but was never used to actually prune candidates
completely. This meant that the labeling obstacle functionality was
confusing and frustrating for users to work with -- because despite
setting layers as the maximum possible blocking weight, you'd still
see labels being placed over these features (e.g. where the labeling
engine had no other choice).
Now, (when a project is set to v2 labeling engine mode), labels will
NEVER be placed over obstacles of greater weight. This means that
labels will potentially be omitted if the only choice is to place
them over a high weighting obstacle. But ultimately, that's much
more understandable for users -- they've manually set a particular
layer to a high obstacle factor, so we should respect that and
never place labels on these features.
In the end, this change makes the labeling placement much simpler
to understand for users, and should give power users a much
nicer experience all round.
Funded by the QGIS grants program
It is obvious that the constructor was a no-op.
Regarding the destructor, taking a mutex around an object doesn't
make sense because both the mutex and the object are member variables,
so if the pal object is used correctly, the destructor should only
be called after any other use of the object. And explicit clearing of
a unordered_map is unnecessary.
* [FEATURE] API for rendering frames for mesh vector dataset animation (particles)
Adds a renderer to generate frames that represent particle traces in a vector field of a mesh layer. The renderer cannot be chosen in the current GUI, however crayfish plugin can use API to generate avi/gif files with nice animations representing the movement of (random) particles in the mesh layer vector field.
When a rendering operation was canceled, PAL had very few early
exit points. This often resulted in many canceled rendering operations
burning away in background threads as labeling candidates and solutions
were being generated for jobs which were no longer needed.
Add more exit points and cancel checks throughout various expensive
pal operations, allowing labeling jobs to terminate quickly.
Fixes#32489
the picture item at the cursor drop location instead of the top left
We want the drop location to be the center of the placed item,
because drag thumbnails are usually centered on the mouse cursor
when attempting to identify a CRS specified via WKT
Because:
1. Proj string conversion is lossy, so we will end up with misleading results
2. If proj can't identify the CRS based on the WKT alone, then any CRS it
identifies from a lossy proj conversion will be incorrect
3. Proj is smarter than QGIS, we should trust it and not rely on downstream hacks
(4. I want to implement creation of user CRS via WKT instead of only proj, and
having this hack in place will break things)
