Bug 288297

Summary:	marble displays gpx points in a flickery/unreliable fashion
Product:	[Applications] marble	Reporter:	Vincent de Phily <moltonel>
Component:	general	Assignee:	marble-bugs
Status:	RESOLVED FIXED
Severity:	normal	CC:	tgridel
Priority:	NOR
Version:	unspecified
Target Milestone:	1.4 (KDE 4.9)
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	"geocache" file from http://odbl.dobini.com/geocaches/iecache.gpx

Description Vincent de Phily 2011-12-05 23:44:27 UTC

Version: unspecified (using KDE 4.7.3)
OS: Linux

When loading a gpx file with a lot of named points (for example geocaching, not tracks), there are "holes" at certain zoom levels where no point is displayed although there is ample space for that. Zooming and/or panning will make marble display a different "selection" of points.

Secondly, while panning around the points flicker horribly, and the associated labels move around the points a lot.

Reproducible: Always

Steps to Reproduce:
Load attached file in marble. Zoom in to view most, but not all of Ireland. Pan from the north-east to the south-west. Experiment with more panning and zooming.

Actual Results:
* Many points appear/disappear when panning.
* Rendering flickers a lot.

Expected Results:
* Display as many points as possible without overlapping labels/icons for the current zoom level.
* Make rendering flicker-free.
* Make the algorythm of "which points to display and where to place labels when map is overcrowded" more stable (ideally shouldn't be affected by panning).

I guess there is a hardcoded limit of points to display at once on the map, and that is what is causing the appearing/disappearing points ? If so, consider removing that limit altogether because :
* It is a serious usability issue, having to pan around to make sure I saw all the points.
* It seems not to be needed for performance reasons, as there is no noticeable speed difference with and without the points loaded on my modest desktop hardware.
* There is already a dynamic limit to the number of points displayer at once, courtesy of the "avoid-overcrowding" algorythm.

Comment 1 Vincent de Phily 2011-12-05 23:50:18 UTC

Created attachment 66422 [details]
"geocache" file from http://odbl.dobini.com/geocaches/iecache.gpx

File is a "geocache" from http://odbl.dobini.com/geocaches/iecache.gpx
Decompress to open with marble (too large to attach uncompressed).
File at original url will change (and become smaller) daily, so use the one attached to this report.

Comment 2 Thibaut Gridel 2012-01-25 17:35:15 UTC

Git commit 3032a8b2d6bbf4703acb37bc5a53eeb417f35805 by Thibaut Gridel.
Committed on 25/01/2012 at 18:33.
Pushed by tgridel into branch 'master'.

PlacemarkLayout: use qreal and QRectF where possible

REVIEW: 103777

M  +2    -2    src/lib/PlacemarkPainter.cpp
M  +2    -2    src/lib/VisiblePlacemark.cpp
M  +3    -3    src/lib/VisiblePlacemark.h
M  +12   -11   src/lib/layers/PlacemarkLayout.cpp
M  +3    -3    src/lib/layers/PlacemarkLayout.h

http://commits.kde.org/marble/3032a8b2d6bbf4703acb37bc5a53eeb417f35805

Comment 3 Vincent de Phily 2012-01-27 09:39:42 UTC

Thanks for this commit, I tried the master branch and the flickering is gone :)

But the main problem is still there : only a selection of the displayable ("inside viewport and far enough from other points") points are actualy displayed. It feels like there is a hard limit on the number of displayed points, and that marble simply goes through the list of displayable ones in file order and stops once the limit is reached.

I tried a quick hack of PlacemarkLayout::visiblePlacemarks() but couldn't quite figure out m_weightfilter and TileCoordsPyramid, or indeed wether that's the correct place to look at.

Could you take a look at the remaining problem, or point me towards a solution ? Thanks.

Comment 4 Thibaut Gridel 2012-02-03 20:21:41 UTC

Git commit 79ab28f3175c6a6c2cc7b85534ee139d316a4828 by Thibaut Gridel.
Committed on 03/02/2012 at 00:39.
Pushed by tgridel into branch 'master'.

PlacemarkLayout: limit the placemark number based on used area ratio

The goal is to keep a sane limit on the number of placemarks displayed,
by design, because one doesn't want to completely fill the screen with
placemark names.

REVIEW: 103813

M  +20   -11   src/lib/layers/PlacemarkLayout.cpp
M  +2    -1    src/lib/layers/PlacemarkLayout.h

http://commits.kde.org/marble/79ab28f3175c6a6c2cc7b85534ee139d316a4828

Comment 5 Vincent de Phily 2012-02-03 21:31:09 UTC

Looks all good now, thank you :)