Modify

#13636 closed defect (fixed)

panning is very slow at high zoom <1m

Reported by: letihu@… Owned by: michael2402
Priority: critical Milestone: 16.10
Component: Core mappaint Version:
Keywords: template_report gsoc-core regression performance Cc: michael2402

Description

What steps will reproduce the problem?

  1. Ich kann die Karte nur sehr sehr langsam verschieben, wenn ich unter 1m zoome.
URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-09-06 00:16:07 +0200 (Tue, 06 Sep 2016)
Build-Date:2016-09-05 22:21:00
Revision:10966
Relative:URL: ^/trunk

Identification: JOSM/1.5 (10966 de) Windows 7 64-Bit
Memory Usage: 542 MB / 910 MB (52 MB allocated, but free)
Java version: 1.8.0_101-b13, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: \Display0 1366x768
Maximum Screen Size: 1366x768
Dataset consistency test: No problems found

Plugins:
+ FixAddresses (32796)
+ buildings_tools (32944)
+ jts (32699)
+ scripting (30730)
+ terracer (32699)
+ utilsplugin2 (32815)

Last errors/warnings:
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet
- W: java.io.IOException: Attribution is not loaded yet

Attachments (2)

moving_dashes.gif (13.2 MB) - added by Klumbumbus 13 months ago.
performace.gif (2.8 MB) - added by Klumbumbus 12 months ago.

Change History (24)

comment:1 Changed 13 months ago by Klumbumbus

Keywords: regression added
Priority: normalcritical
Summary: Kartenverschiebung bei Zoom unter 1mpanning is very slow at high zoom

I noticed this too. there is a high cpu load just from zooming in and josm hangs (with just a few buildings and a street loaded).

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-09-13 15:07:08 +0200 (Tue, 13 Sep 2016)
Build-Date:2016-09-14 01:38:16
Revision:10998
Relative:URL: ^/trunk

Identification: JOSM/1.5 (10998 de) Windows 7 32-Bit
Memory Usage: 678 MB / 870 MB (102 MB allocated, but free)
Java version: 1.8.0_101-b13, Oracle Corporation, Java HotSpot(TM) Client VM
Screen: \Display0 1680x1050
Maximum Screen Size: 1680x1050
VM arguments: [-Djava.security.manager, -Djava.security.policy=file:<java.home>\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=C:\Program Files\josm-latest-bla.jnlp, -Djnlpx.remove=true, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.heapsize=256m,900m, -Djnlpx.splashport=62905, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.vmargs=LURqYXZhLnV0aWwuQXJyYXlzLnVzZUxlZ2FjeU1lcmdlU29ydD10cnVlAA==]
Dataset consistency test: No problems found

Plugins:
+ AddrInterpolation (32699)
+ DirectDownload (32699)
+ DirectUpload (32699)
+ HouseNumberTaggingTool (32699)
+ OpeningHoursEditor (32699)
+ alignways (32921)
+ apache-commons (32699)
+ apache-http (32699)
+ buildings_tools (32944)
+ editgpx (32699)
+ imagery_offset_db (32796)
+ log4j (32699)
+ photo_geotagging (32699)
+ photoadjust (32863)
+ reverter (32796)
+ tag2link (32941)
+ tagging-preset-tester (32869)
+ terracer (32699)
+ turnlanes-tagging (245)
+ turnrestrictions (32796)
+ undelete (32699)
+ utilsplugin2 (32815)
+ wikipedia (32884)
Last edited 13 months ago by Klumbumbus (previous) (diff)

comment:2 Changed 13 months ago by Klumbumbus

Summary: panning is very slow at high zoompanning is very slow at high zoom <1m

comment:3 Changed 13 months ago by Klumbumbus

Cc: michael2402 added
Component: CoreCore mappaint
Keywords: gsoc-core added
Milestone: 16.09

r10823 works fine, r10836 doesn't. I guess a regression of r10827

comment:4 Changed 13 months ago by michael2402

Ticket #13650 has been marked as a duplicate of this ticket.

comment:5 Changed 13 months ago by michael2402

Owner: changed from team to michael2402
Status: newassigned

comment:6 Changed 13 months ago by Klumbumbus

Keywords: performance added

comment:7 Changed 13 months ago by michael2402

In 11026/josm:

See #13636: Add automated clipping to MapViewPath.

comment:8 Changed 13 months ago by michael2402

In 11027/josm:

See #13636: Speed up map paint by clipping the way segments.

comment:9 Changed 13 months ago by Klumbumbus

Performance seems fine again. However now we have a problem with "moving" dashes when the beginning of the way is outside the mapview. See e.g. the dashes for admin boundary, maxspeed:conditional on motorway (with maxspeed mappaint style), railways or paths at the following screencast:

Changed 13 months ago by Klumbumbus

Attachment: moving_dashes.gif added

comment:10 Changed 13 months ago by michael2402

Yes, this is one reason I kept this open. It is a bit harder to fix - I cannot set the dash offset on the stroke since the way may have multiple start points. I have an idea on how to fix it (do clamping in a separate step before the way is drawn and when we know the stroke).

I still have performance problems on borders of multipolygon boundaries in some cases. I guessed it was a problem with the contour line for the non-filled areas. But clamping that did not improve the performance. It seems to be related to view caching, it improves if I disable the buffered image in between.

comment:11 Changed 13 months ago by simon04

Milestone: 16.0916.10

Milestone renamed

comment:12 Changed 13 months ago by Roadsguy

I'm running 10966 on Windows 10, Java 8u101 x64, and the slow performance in general on high zoom is definitely still present.

comment:13 in reply to:  12 Changed 12 months ago by simon04

Replying to Roadsguy:

I'm running 10966 on Windows 10, Java 8u101 x64, and the slow performance in general on high zoom is definitely still present.

Yes, sure. It has been fixed in r11026/r11027.

@michael2402: Besides the moving dashes, is there something to be done, i.e., does this block the next stable release?

comment:14 Changed 12 months ago by michael2402

No, it is just a cosmetic problem.

comment:15 in reply to:  9 Changed 12 months ago by simon04

Resolution: fixed
Status: assignedclosed

Alright. Let's track the moving dashes in #13793.

comment:16 in reply to:  14 Changed 12 months ago by Klumbumbus

Replying to michael2402:

No, it is just a cosmetic problem.

The moving dashes can be very annoying. It would be nice if it could be fixed in 16.10.

Changed 12 months ago by Klumbumbus

Attachment: performace.gif added

comment:17 Changed 12 months ago by Klumbumbus

Resolution: fixed
Status: closedreopened

Sorry to reopen this again, but it seems I didn't completely check this. The performance was improved only a bit in r11026/r11027. Map moving is still extremely slow at high zoom levels (framerate < 1/s). See the screencast, which was created with current latest r11146 (same behavior also with r11030).

With r10823 (i.e. before r10827) I get a fluet panning even on the highest zoom level (however there are moving dashes).

I did't check performance on larger data sets.

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-10-18 20:32:20 +0200 (Tue, 18 Oct 2016)
Build-Date:2016-10-19 01:34:39
Revision:11146
Relative:URL: ^/trunk

Identification: JOSM/1.5 (11146 de) Windows 7 32-Bit
Memory Usage: 452 MB / 870 MB (85 MB allocated, but free)
Java version: 1.8.0_111-b14, Oracle Corporation, Java HotSpot(TM) Client VM
Screen: \Display0 1680x1050
Maximum Screen Size: 1680x1050
VM arguments: [-Djava.security.manager, -Djava.security.policy=file:<java.home>\lib\security\javaws.policy, -DtrustProxy=true, -Djnlpx.home=<java.home>\bin, -Djnlpx.origFilenameArg=C:\Program Files\josm-latest-bla.jnlp, -Djnlpx.remove=true, -Djava.util.Arrays.useLegacyMergeSort=true, -Djnlpx.heapsize=256m,900m, -Djnlpx.splashport=56854, -Djnlpx.jvm=<java.home>\bin\javaw.exe, -Djnlpx.vmargs=LURqYXZhLnV0aWwuQXJyYXlzLnVzZUxlZ2FjeU1lcmdlU29ydD10cnVlAA==]
Dataset consistency test: No problems found
Last edited 12 months ago by Klumbumbus (previous) (diff)

comment:18 Changed 12 months ago by michael2402

Thanks for reporting.

The one way arrows cause that problem. I fixed it in [11147] by using the same solution as with the dashed lines.

Feel free to re-open if you find any more issues or any features that cause the same problem.

Last edited 12 months ago by michael2402 (previous) (diff)

comment:19 Changed 12 months ago by michael2402

Resolution: fixed
Status: reopenedclosed

comment:20 Changed 12 months ago by Klumbumbus

Thanks for fast fix :)

comment:21 Changed 12 months ago by bastiK

Resolution: fixed
Status: closedreopened

The repeat-image MapCSS property is similar. (in StyledMapRenderer.drawRepeatImage(); e.g. default style for a way tagged natural=cliff)

comment:22 Changed 12 months ago by michael2402

Resolution: fixed
Status: reopenedclosed

In 11148/josm:

Fix #13636: Use clipping for images on a line (RepeatImageElement).

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain michael2402.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.