[patch] JOSM lagging with over 500ms delay

[Korgi1]

What steps will reproduce the problem?

1. Open JOSM
2. Download Data
3. Attempt to edit or add any polygon or line data

What is the expected result?

JOSM works smoothly

What happens instead?

JOSM runs with extreme lag as if im using it on a 90s PC.

Please provide any additional information below. Attach a screenshot if possible.

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2022-01-02 21:24:43 +0100 (Sun, 02 Jan 2022)
Build-Date:2022-01-02 20:26:19
Revision:18360
Relative:URL: ^/trunk

Identification: JOSM/1.5 (18360 en) Windows 10 64-Bit
OS Build number: Windows 10 Home 2009 (19042)
Memory Usage: 465 MB / 1820 MB (270 MB allocated, but free)
Java version: 1.8.0_271-b09, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Screen: \Display0 2560×1440 (scaling 1.00×1.00) \Display1 1920×1080 (scaling 1.00×1.00)
Maximum Screen Size: 2560×1440
Best cursor sizes: 16×16→32×32, 32×32→32×32
System property file.encoding: Cp1252
System property sun.jnu.encoding: Cp1252
Locale info: en_US
Numbers with default locale: 1234567890 -> 1234567890

Plugins:
+ HouseNumberTaggingTool (35893)
+ PicLayer (1.0.2)
+ apache-commons (35893)
+ buildings_tools (35916)
+ conflation (0.6.9)
+ ejml (35893)
+ geotools (35906)
+ imagery_offset_db (35893)
+ jaxb (35893)
+ josm-batch-downloader (1.0.4)
+ jts (35893)
+ measurement (35893)
+ turnrestrictions (35893)
+ utilsplugin2 (35893)
+ waydownloader (35893)

Last errors/warnings:
- 00002.386 W: Unable to request certificate of https://grca.nat.gov.tw

[Korgi1]

JOSM status report

[taylor.smock]

1.8.0_271-b09

Can you please either (a) update Java (Java 8 Update 321 is available) or (b) use the provided installer on the JOSM homepage. You are not using any of the plugins that have problems with later versions of Java (AFAICT -- kendzi3d is an example), so you should be able to run JOSM with Java 17, which is what the provided installer uses.

If the problem still persists, can you please add a link to the area you are editing or (preferably) the value of the advanced preference osm-download.bounds.

EDIT: The osm-download.bounds was in the status report (osm-download.bounds=34.2849674;129.3487599;34.2868666;129.3517318).

EDIT2: I am not seeing any kind of extreme lag on Mac with Java 11.0.12+7. Maybe a screencapture would help. I am seeing some lag in a linux VM, but that is more likely due to the VM (Fedora, Java 1.8.0_322-b06).

[Korgi]

laptop pref info

[Totally Korgi]

home PC prefs file

[Korgi1]

Per request of taylor.smock, I attempted updating java, rolling back osm, and resetting preferences to no change.

[taylor.smock]

@Korgi1: As a workaround, try disabling Draw map boundaries of downloaded data to see if that helps. It should.

I did a bit of profiling with the home pc.xml settings.

Steps to reproduce profiling:
1) Import settings from attachment:"home pc.xml"​
2) Attach profiler (I used async profiler) once initial download area has been downloaded (use the area from home pc.xml for reproducibility)
2a) Optionally add Bing aerial imagery prior to attaching profiler
4) Pan in a circle for 30-60 seconds.

Results:

• EDT takes up 48.14% of the CPU time, 91.98% of the memory allocations. We don't care about the other threads, since they don't have an immediate impact upon UI performance for this bug.
• OsmDataLayer#paint takes up 38.49% of CPU time (79.95% of EDT), 81.47% of memory allocations (88.57% of EDT allocations)

At this point, the memory allocations and CPU time split. The vast majority of memory allocations occur in StyledMapRenderer#render while a disproportionate amount of time is spent drawing the hatched area.

• StyledMapRenderer#render takes up 12.64% of CPU time (26.25% of EDT), 71.83% of memory allocations (88.16% of EDT allocations)
• SunGraphics2D#fill (for the hatched undownloaded area) takes up 25.51% of CPU time (52.99% of EDT) (10.38% of EDT allocations when accounting for the bits leading up to fill)

In short, to increase performance of the EDT (UI) thread, we need to figure out how to draw the hatched area more efficiently.

EDIT: Korgi1 reported that the workaround did not help on OSM Discord.

[taylor.smock]

Korgi has reported a workaround on OSM World Discord (12:41PM MDT, March 14, 2022).

ok so. Theres this game called project zomboid ​https://store.steampowered.com/app/108600/Project_Zomboid/. If i open this game and cause it to crash, JOSM stops lagging. If i terminate the crashed program, the lag returns
[...]
[...] i just load a mod for the wrong version but it doesnt matter how i [crash Project Zomboid]

I have no clue how that works. The only package I see in common (from ​https://projectzomboid.com/modding/ ) is vecmath (used in kendzi3d, which @Korgi1 isn't using).

[anonymous]

JFR FILE

[taylor.smock]

Test jar file for not updating auto filters during pan

[taylor.smock]

Avoid updating buttons during panning

[gaben]

Is the attached patch improves the situation?

[taylor.smock]

I don't recall if I got a response from Korgi1 about whether or not. I want to say he said it didn't help. Without access to the machine (which I think I either didn't ask for, or specifically said he shouldn't give access to random people on the internet), I was unable to debug further.