Bug report #11441

Parallel multi-core rendering glitches with OTF reprojection

Added by Anita Graser about 10 years ago. Updated almost 7 years ago.

Status:Closed
Priority:Normal
Assignee:-
Category:Map Canvas
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:No Resolution:fixed/implemented
Crashes QGIS or corrupts data:No Copied to github as #:19717

Description

With active on-the-fly reprojection and parallel rendering, the map renders with big artifacts. I've tested the following project with both the 2.4 release and today's nightly:

https://github.com/FOSS4GAcademy/GST101FOSS4GLabs/tree/master/Module%204%20Lab/QGIS%202.2/Lab%204%20Data

Deactivating either OTF or parallel rendering fixes the problem as far as I can tell.

glitch.png (236 KB) Anita Graser, 2014-10-19 03:23 AM

projissues.PNG (223 KB) Anita Graser, 2016-01-23 10:32 AM

glitch219.PNG (211 KB) Anita Graser, 2017-01-09 11:12 AM

Related issues

Related to QGIS Application - Bug report #11746: Vertical lines appear as artifacts when map has lots of l... Closed 2014-11-26

Associated revisions

Revision 4396e532
Added by Nyall Dawson over 7 years ago

Utilise thread safe proj API within QgsCoordinateTransform

Avoids unpredictable behavior when transforms are being
conducted in background threads, such as map renders.

Refs #11441

This commit:
1. Uses thread_local storage for projCtx objects, to ensure
that every thread correctly has its own projCtx context.

2. Refactors QgsCoordinateTransformPrivate so that the
projPJ source and destination objects are instead stored
in a map (by projCtx). This allows transforms to be
transparently performed using the correct projPJ objects
for the particular thread in which the transform is being
conducted. This approach avoids expensive detachment
of QgsCoordinateTransformPrivate, and allows a single
QgsCoordinateTransformPrivate to be safely utilised
by QgsCoordinateTransform objects in different threads.

Revision af3370d0
Added by Nyall Dawson over 7 years ago

Utilise thread safe proj API within QgsCoordinateTransform

Avoids unpredictable behavior when transforms are being conducted
in background threads, such as map renders.

Refs #11441

This commit:
1. Uses QThreadStorage for projCtx objects, to ensure that every
thread correctly has its own projCtx context

2. Refactors QgsCoordinateTransform so that the projPJ source and
destination objects are instead stored in a map (by projCtx). This
allows transforms to be transparently performed using the correct
projPJ objects for the particular thread in which the transform is
being conducted. This approach allows a single QgsCoordinateTransform
to be safely utilised in different threads.

History

#1 Updated by Giovanni Manghi about 10 years ago

  • Status changed from Open to Feedback

cannot confirm here, tested on master on both Linux and Windows (same project and data).

#2 Updated by Gary Sherman about 10 years ago

Try turning off simplification and/or "Make lines appear less jagged..." and see if it goes away. We had a similar problem years ago and I don't recall the root cause.

#3 Updated by Saber Razmjooei about 10 years ago

There are layers from outside the OTF CRS. According to this website: http://prj2epsg.org/epsg/5070 Canada and Mexico are outside EPSG:5070's CRS zone. I guess this causes the problem.

I have removed Mexico and Canada and the problem seems to have disappeared.

#4 Updated by Anita Graser about 10 years ago

@Gary: Changing the simplification settings (values, on/off) or deactivating anti-aliasing didn't change the results.

@Saber: Even if I only use the US states (which should be within the CRS zone), these artifacts appear.

#5 Updated by Saber Razmjooei about 10 years ago

It has become less frequent. To completely get rid of the problem, I saved western_states in 5070 and used that instead. But that does not explain the source of problem.

#6 Updated by Martin Dobias about 10 years ago

I cannot replicate the problem.

@Anita / @Saber - which version of Proj.4 do you use? Does it happen also if you use a wgs84 for destination CRS? To my (brief) knowledge, the used epsg 5070 uses a grid file. Could you try some other projection for north america that does not involve reading of grid files? (based on parameters only)

Apparently the proj library versions < 4.8 were prone to errors when used in multi-threaded environment, but maybe we should also make use of contexts introduced in 4.8:
https://trac.osgeo.org/proj/wiki/ThreadSafety

#7 Updated by Giovanni Manghi about 10 years ago

Martin Dobias wrote:

I cannot replicate the problem.

@Anita / @Saber - which version of Proj.4 do you use? Does it happen also if you use a wgs84 for destination CRS? To my (brief) knowledge, the used epsg 5070 uses a grid file. Could you try some other projection for north america that does not involve reading of grid files? (based on parameters only)

Apparently the proj library versions < 4.8 were prone to errors when used in multi-threaded environment, but maybe we should also make use of contexts introduced in 4.8:
https://trac.osgeo.org/proj/wiki/ThreadSafety

it seems anyway strange to me as I tested also on Windows (where anyone should have the same libraries) and cannot replicate the issue.

#8 Updated by Martin Dobias about 10 years ago

Giovanni Manghi wrote:

it seems anyway strange to me as I tested also on Windows (where anyone should have the same libraries) and cannot replicate the issue.

Unfortunately this is not that strange. It is quite common that errors in multi-threaded code appear just for some people, while working flawlessly for others.

#9 Updated by Saber Razmjooei about 10 years ago

It works fine in both WGS84 and 4269.

#10 Updated by Giovanni Manghi almost 10 years ago

still true?

#11 Updated by Anita Graser almost 10 years ago

Still true for me (Win8 OSGeo4W nightly 64bit).

#12 Updated by Giovanni Manghi over 9 years ago

  • Status changed from Feedback to Open

#13 Updated by Anita Graser over 9 years ago

Still true for 2.8.1 (Win8 OSGeo4W 64bit).

#14 Updated by Anita Graser about 9 years ago

  • Target version set to Future Release - High Priority

Still true for 2.11 today.

#15 Updated by Martin Dobias almost 9 years ago

  • Status changed from Open to Feedback

As far as I can tell from my tests, this problem was caused by a bug in proj.4 library: https://github.com/OSGeo/proj.4/issues/226

It has been fixed in proj 4.9.2 (released Sep 2015) which is now also available in osgeo4w (since end of Nov 2015). Could you please test again with the latest proj4 version to see if the problem is gone?

#16 Updated by Anita Graser almost 9 years ago

Unfortunately still around ... even with the new proj ..

Please put back to "open".

#17 Updated by Anita Graser over 8 years ago

@Martin Can you please change the status back to open? Thanks!

#18 Updated by Martin Dobias over 8 years ago

  • Status changed from Feedback to Open

Maybe we can have a look at it in Girona...

#19 Updated by Giovanni Manghi almost 8 years ago

  • Status changed from Open to Feedback

is there any update on this issue?

#20 Updated by Anita Graser almost 8 years ago

Still same error unfortunately. Tested with latest 2.19 in OSGeo4W - so not latest master

#21 Updated by Jürgen Fischer almost 8 years ago

Anita Graser wrote:

so not latest master

not even master - qgis-dev is from (removed) master_2. qgis-rel-dev should be more up to date (branched off from master_2 on release of 2.18)

#22 Updated by Giovanni Manghi almost 8 years ago

  • Status changed from Feedback to Open

Jürgen Fischer wrote:

Anita Graser wrote:

so not latest master

not even master - qgis-dev is from (removed) master_2. qgis-rel-dev should be more up to date (branched off from master_2 on release of 2.18)

There will ever be a master/qgis3 package on osgeo4w? Just a practical question: I do/did most of master testing on Windows because it was very practical, if there will be no more master on osgeo4w I will have to review my strategy and compile daily on Linux.

#23 Updated by Jürgen Fischer almost 8 years ago

Giovanni Manghi wrote:

There will ever be a master/qgis3 package on osgeo4w?

sure.

#24 Updated by Anita Graser almost 8 years ago

Jürgen Fischer wrote:

qgis-rel-dev should be more up to date (branched off from master_2 on release of 2.18)

Ok, I'll try with qgis-rel-dev

#25 Updated by Anita Graser almost 8 years ago

Same issue in qgis-rel-dev

#26 Updated by Giovanni Manghi over 7 years ago

  • Affected QGIS version changed from master to 2.18.4
  • Status changed from Open to Feedback
  • Priority changed from High to Normal
  • Target version deleted (Future Release - High Priority)

Anita Graser wrote:

Same issue in qgis-rel-dev

what about the (qgis3) master? any change?

#27 Updated by Anita Graser over 7 years ago

Still same here with 2.99 from OSGeo4W.

#28 Updated by Giovanni Manghi over 7 years ago

  • Target version set to Version 3.0
  • Status changed from Feedback to Open
  • Affected QGIS version changed from 2.18.4 to master

#29 Updated by Giovanni Manghi over 7 years ago

  • Regression? set to No
  • Easy fix? set to No

#30 Updated by Nyall Dawson over 7 years ago

  • Status changed from Open to Feedback
  • Description updated (diff)

Anita - please test the next nightly 3.0 release as this is likely fixed now.

#31 Updated by Nyall Dawson almost 7 years ago

Anita -can we close this? Should be fixed in master and recent 2.18

#32 Updated by Anita Graser almost 7 years ago

  • Status changed from Feedback to Closed
  • Resolution set to fixed/implemented

Looks good! Thanks Nyall!

Also available in: Atom PDF