[Merkaartor] Panning with many map objects is slow

[Chris Browet]

Now that you say it, it's quite logical. Due to projection, changing the
latitude of the viewport also changes the pixel/meter value.

Anyway, as said in my previous message, I cannot see why we should re-sort,
even when zooming.
The only use of re-sorting is when sorting roads, where we get the painter
(which is pixel/m depended) to check whether the road is to be filled.
Checking if the road is an area is good enough, as in the current case, the
area() call will return 0 for non-closed roads, whatever their actual
"surface", which will paint them last anyway.

- Chris -

On Sun, Jan 11, 2009 at 5:23 PM, Yves Goergen
<nospam.list at unclassified.de>wrote:

> I have more details now.
>
> Sorting itself is only done under the condition that the map layer
> contents have been changed (false) or that the value of "PixelPerM" has
> changed since the last call (true).
>
> This true condition attracted my attention. With debug output I saw that
> the value only changes a tiny bit, and only when panning vertically
> (north-south). It virtually does not change panning horizontally
> (west-east). In fact, if you watch hard enough and pan exactly only in X
> direction, the painting goes much faster than in Y direction.
>
> The pixel per M (metres?) value is passed on and used somewhere in the
> painter, maybe to determine whether an element shall be displayed or
> not. But since such small variations most likely won't affect this, I
> guess such tiny offsets can be safely ignored.
>
> As I'm writing this, I have now added a threshold so that the sorting is
> not called when the value has changed at all (which is effectively every
> time), but only if the value has changed by more than 0.0002.
>
> The result is quite good: I have downloaded 100 km² in two steps.
> Panning is now very quick on all zoom levels and I cannot find any
> rendering errors.
>
> This fix only affects panning, where the PixelPerM value doesn't change
> too much. Zooming changes this value by factor 2 and thus sorting still
> needs to be done. Zooming from one level to another takes almost a whole
> second now with that "huge" amount of data loaded.
>
> --
> Yves Goergen "LonelyPixel" <nospam.list at unclassified.de>
> Visit my web laboratory at http://beta.unclassified.de
>
> _______________________________________________
> Merkaartor mailing list
> Merkaartor at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/merkaartor
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/merkaartor/attachments/20090111/532138e4/attachment.html>