about draw.rawgps.max-line-length cost of computation

[anonymous]

At the moment you (re-)compute the distance fairly oftern, if I understand it correctly. However, if the assumption "if a org.openstreetmap.josm.data.gpx.WayPoint has a previous org.openstreetmap.josm.data.gpx.WayPoint, that will never change" is true, you could cache the result of the computation in org.openstreetmap.josm.data.gpx.WayPoint. e.g.

org.openstreetmap.josm.data.gpx.WayPoint: 19 public int cachedDistance = -1;

org.openstreetmap.josm.gui.layer.GpxLayer: 323 if (maxLineLength > -1) { 324 if (trkPnt.cachedDistance <= -1) 325 trkPnt.cachedDistance = trkPnt.latlon.distance(oldWp.latlon); 326 if (trkPnt.cachedDistance > maxLineLength) continue; 327 }

[framm]

I think that the assumption may be broken by loading new GPX data (which might just be sorted in between the existing data, I'm not sure) but in that case one could clear the cache on loading.

[ramack]

I don't think that data will be sorted in between atm. But updating the distance cache should be easy on inserting new data.

[Henry Loenwind]

I thought on storing a flag about the validity of the data in the layer instead in the points. So it can easily be cleared when loading data or merging layers. I think, I'll separate the compute-loop from the draw-loop, too. That may save some ifs in the draw loop.

[Henry Loenwind]

ok, here's the patch.

I added 2 new configuration values (einstein mode only for now):

draw.rawgps.alternatedirection Set to "true" to have arrows drawn with less math. They will be off by up to 22.5°, but MAY be rendered faster. On my machine the effect was not really noticeable.

draw.rawgps.trianglelines Set to "true" to have lines rendered as 2 lines, like the arrow lines, but over the whole length of the line. Does not look really nice, but on my machine this renders more than 10 times faster than straight lines!

[Henry Loenwind]

Patch v2

[Henry Loenwind]

a minor update for the patch, no need to paint the arrows if the line was ommited because it would have had 0-length

[ramack]

patch from #966 applied in [721]