Painting error layer is very slow

[bilbo]

When error layer in validator is visible and being painted, scrolling through the map is very slow - with medium size map (~ 8000 ways, 32000 nodes), when I zoom in close, the scrolling is smooth, however if I turn on the error layer, the scrolling goes to about 1 redraw per 2 seconds.

I suspect that the error layer is not using quad buckets or any similar algorithm to speed things up and only draw things that are actually visible.

Although, even when zoomed out (so entire map is visible), the redraw speed is much worse (approximately 3 to 5 times slower with the error layer than without it)

[skyper]

Hopefully, [5671] did improve this situation.

[Don-vip]

@Michael: I tried to rework the validation layer painting but I failed to get any improvement.
What I saw using my sample data set (work.osm) with information level enabled (more than 1000 error items) and displaying the full view:

• painting OSM data layer alone takes about 50ms
• painting validator layer alone takes about 50ms
• painting both layers takes:
  • about 50 ms for the OSM data layer
  • then about 300 ms for the validator layer! most of the time is spent in Graphics.drawArc methods but I don't understand why it is slower if the OSM data layer has been previously painted. Any clue?

I tried to change a lot of things, including dropping the direct Java2D rendering to use MapViewPath. The resulting code is simpler, but not faster.

Do you see how to improve the situation?

[michael2402]

@Don-vip

It could be some setting that the layer sets for the graphics instance.

You could try:

g.setRenderingHint(RenderingHints.KEY_ANTIALIASING, RenderingHints.VALUE_ANTIALIAS_OFF);
g.setRenderingHint(RenderingHints.KEY_TEXT_ANTIALIASING, RenderingHints.VALUE_TEXT_ANTIALIAS_OFF);

[taylor.smock]

I just did a bit of profiling on the validation layer.
~1/3 of the memory allocations is from hashCode calls (from HashMap/HashSet), most of which are from LatLon.hashCode.
A good chunk of the CPU usage is also in the HashSet/HashMap calls, but not as bad.

We can probably improve performance a bit by moving LatLon.hashCode from Objects.hash to something that (a) doesn't box the doubles and (b) doesn't create an array. See r9375. So something like 31 * Double.hashCode(x) + Double.hashCode(y) would work. That should reduce GC stop-the-world events.

Another thing we can do to reduce GC pressure is make PaintedSegment take ILatLon as a parameter instead of LatLon. This will let us pass Node in instead of creating a (new) LatLon object from the Node.

Something else we can do (to reduce GC pressure) is to make isSegmentVisible take points, and calculate the points once instead of twice.

That still doesn't help with the drawArc CPU usage situation though.

As an alternative to the current method of drawing the validation layer on every render loop, have we considered doing something like #11487 (render data to tiles)?