Bug report #11909

Pre-rendered map display does not respect rotation

Added by Sandro Santilli about 9 years ago. Updated almost 9 years ago.

Status:Closed
Priority:Normal
Assignee:Sandro Santilli
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 #:20119

Description

The map shown on zoom/pan events as a placeholder while renderer completes his work in a thread does not take rotation in consideration.
This means that a rotated map is placed in the wrong place until renderer completes, giving a "jumpy" effect to the experience.

See further discussion in issues #11811

One known problem is a limitation of the QgsMapCanvasItem interface which allows to set the position and size of an item by specifying its spatial extent (in map coordinate space) which tipically users obtain by asking for the "visible extent" of the MapCanvas. In presence of rotation, the upper-left corner of the visible extent is usually outside of the viewport.

pan_rotated.mp4 (2.69 MB) Mathieu Pellerin - nIRV, 2015-01-03 11:22 PM

pan_rotated_better.mp4 (596 KB) Mathieu Pellerin - nIRV, 2015-01-03 11:23 PM

History

#1 Updated by Mathieu Pellerin - nIRV about 9 years ago

IMO, this shouldn't be a feature request. It's an implementation issue. But that's all semantic :) it however would have to be dealt with before allowing for a status bar rotation box as for the average user, the visual jump is not a great experience.

#2 Updated by Nathan Woodrow about 9 years ago

  • Tracker changed from Feature request to Bug report
  • Affected QGIS version set to 2.6.0
  • Crashes QGIS or corrupts data set to No

#3 Updated by Sandro Santilli about 9 years ago

  • Affected QGIS version changed from 2.6.0 to master

#4 Updated by Sandro Santilli about 9 years ago

  • Resolution set to fixed/implemented
  • Status changed from Open to Closed
  • % Done changed from 0 to 100

Fixed with commit 888a9f0bfce881bc479250b0d76a52b7371c92d8

#5 Updated by Mathieu Pellerin - nIRV about 9 years ago

Sandro, still not fixed for me, see video capture attached.

I've tried on three different projects, with OTF reprojection on and off, same result, the jumps are still there.

#6 Updated by Mathieu Pellerin - nIRV about 9 years ago

Here's an ever better video, showing jumps with a simple project of two layers (the forest cover is quite a large dataset, ideal to witness the jump).

I noticed the actual incremental drawing of the forest cover polygons are drawn at the wrong location, until all of the layer is drawn.

#7 Updated by Sandro Santilli about 9 years ago

The way I try to witness the jump is unchecking the "Renderer" checkbox and panning/zooming/rotating and finally re-check "Renderer" to verify the rendered map is at the same location as the pre-rendered one.

It works for me with a raster layer and two vector layers (postgis and memory).
Where does your forest cover comes from ?

#8 Updated by Sandro Santilli about 9 years ago

After obtaining the shapefile of the land cover I could still not reproduce.
My rendering options are: do not use rendere caching, do not use parallel layers rendering, map update interval: 250ms.
I confirm with "Render" unchecked everything looks fine, so the jump you see might be coming from a partial rendering event.

#9 Updated by Sandro Santilli about 9 years ago

I see it takes "Render layers in parallel using many CPU cores" to trigger the jumping. Do you confirm ?

#10 Updated by Sandro Santilli about 9 years ago

The problem is likely with the QgsMapCanvasMap (item) being updated on "rendererJobFinished" event which is "late".
Doesn't take any special layer to reproduce, can be done also with a simple one.
It needs rendering to be activated but shows only until it is not complete.
Martin, do you have any trick to make the "partial" rendering visible, avoiding a completion event ?

#11 Updated by Sandro Santilli about 9 years ago

Oh another thing: the "jump" can be made more visible with simple layers by reducing the "Map update interval" to 0ms (Options,Rendering) If the interval is larger than the time it takes to complete the rendering, no jump can be notable.

#12 Updated by Sandro Santilli about 9 years ago

Partial rendering fixed with commit 41da5c35f833a4d03d6f97c4dcbe4a246f75f943
Mathieu please confirm

#13 Updated by Mathieu Pellerin - nIRV about 9 years ago

Sandro, excellent, progressive / partial rendering working just fine now. Huge step forward.

#14 Updated by Sandro Santilli almost 9 years ago

I'm seeing the jump on partial/progressive rendering again, can anyone confirm ? Both in 2.8 branch and master

#15 Updated by Sandro Santilli almost 9 years ago

  • Status changed from Closed to Reopened

10d2ce45847d781719963ae8b49e21b6c84036db does not show the jump on progressive rendering, 3229813fb4d085ac84210717afc06731e0a883ff does, Im' bisecting...

#16 Updated by Sandro Santilli almost 9 years ago

  • Status changed from Reopened to Closed

Oops, sorry I just realized this is really not a regression. Jumping only happens on changing rotation, not scale or position.
If worth, it's better to use a separate ticket for this.

Also available in: Atom PDF