Modify

Opened 13 years ago

Last modified 7 months ago

#5641 new defect

Painting error layer is very slow

Reported by: bilbo Owned by: team
Priority: normal Milestone:
Component: Core validator Version: latest
Keywords: performance gsoc-candidate Cc: michael2402

Description (last modified by skyper)

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)

Attachments (2)

patch.diff (20.8 KB ) - added by Don-vip 4 years ago.
work.osm (3.1 MB ) - added by Don-vip 4 years ago.

Change History (9)

comment:1 by bastiK, 13 years ago

Priority: majornormal

comment:2 by skyper, 11 years ago

Component: CoreCore validator
Description: modified (diff)

Hopefully, [5671] did improve this situation.

comment:3 by Don-vip, 10 years ago

Keywords: performance added

comment:4 by Don-vip, 5 years ago

Keywords: gsoc-candidate added

by Don-vip, 4 years ago

Attachment: patch.diff added

by Don-vip, 4 years ago

Attachment: work.osm added

comment:5 by Don-vip, 4 years ago

Cc: michael2402 added

@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?

comment:6 by michael2402, 4 years ago

@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);
Last edited 4 years ago by Don-vip (previous) (diff)

comment:7 by taylor.smock, 7 months ago

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)?

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from team to the specified user.
Next status will be 'needinfo'. The owner will be changed from team to bilbo.
as duplicate The resolution will be set to duplicate. Next status will be 'closed'. The specified ticket will be cross-referenced with this ticket.
The owner will be changed from team to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.