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)
If the number of candidates is < the number of features (i.e. some features have
no candidates), we'll get a crash. And if the number of candidates >> number of features
(the usual case), we're just creating a much larger vector than we'll ever use...
(I think. It's pal. No-one know for sure.)
