[PATCH] Very slow at Wireframe view with large data set

[Nzara]

What steps will reproduce the problem?

1. Have Wireframe view disabled
2. Load a large amount of data (100k nodes, 25k ways, 1k relations)
3. Zoom and Pan
4. enable Wireframe view (View-> Wireframe View)
5. Zoom and Pan

What is the expected result?

• GUI is same responsive in wireframe view as in normal view

What happens instead?

zoom to data / zoom in / zoom out / Enable wireframe view / etc. - all make the system unresponsive for about 20 Seconds.

Other observations

• All operations in normal view take a fraction of a second
• purging half the data reduces unresponsive time in wireframe view to 5 seconds
• wireframe view gets faster, if less data is visible

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

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2024-07-02 17:10:50 +0200 (Tue, 02 Jul 2024)
Revision:19128
Build-Date:2024-07-03 01:31:15
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (19128 en) Windows 11 64-Bit
OS Build number: Windows 10 Home 23H2 (22631)
Memory Usage: 634 MB / 4076 MB (226 MB allocated, but free)
Java version: 21.0.4+7-LTS, Azul Systems, Inc., OpenJDK 64-Bit Server VM
Look and Feel: com.sun.java.swing.plaf.windows.WindowsLookAndFeel
Screen: \Display0 3840x2160x32bpp@59Hz (scaling 1.25×1.25)
Maximum Screen Size: 3840×2160
Best cursor sizes: 16×16→32×32, 32×32→32×32
System property file.encoding: UTF-8
System property sun.jnu.encoding: Cp1252
Locale info: en_CH
Numbers with default locale: 1234567890 -> 1234567890
VM arguments: [-Djosm.home=D:/JOSM/Home, --add-exports=java.base/sun.security.action=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.plugins.jpeg=ALL-UNNAMED, --add-exports=java.desktop/com.sun.imageio.spi=ALL-UNNAMED]
Program arguments: [--debug, --skip-plugins]
Dataset consistency test: No problems found

Last errors/warnings:
- 00001.216 W: extended font config - overriding 'filename.Malgun_Gothic=malgun.ttf' with 'MALGUN.TTF'
- 00001.222 W: extended font config - overriding 'filename.Myanmar_Text=mmrtext.ttf' with 'MMRTEXT.TTF'
- 00001.225 W: extended font config - overriding 'filename.Mongolian_Baiti=monbaiti.ttf' with 'MONBAITI.TTF'

[taylor.smock]

In my testing, it looks like relations are the most likely problem -- I use an overpass download of ​Mesa County for my testing, and that has ~700 relation. For testing purposes, I zoomed to ​osmwww:way/661336152
The render loop is dominated by Relation.accept from WireframeMapRenderer.render.

src/org/openstreetmap/josm/data/osm/visitor/paint/WireframeMapRenderer.java

@@ -177 +177 @@
                     way.accept(this);
                 }
             }
+            displaySegments();
         }
         displaySegments();
 
@@ -351 +352 @@
         }
         g.setColor(col);
 
+        Bounds viewArea = mapState.getViewArea().getLatLonBoundsBox();
         for (IRelationMember<?> m : r.getMembers()) {
             if (m.getMember().isIncomplete() || !m.getMember().isDrawable()) {
                 continue;
             }
 
-            if (m.isNode()) {
+            if (m.isNode() && viewArea.contains((INode) m.getMember())) {
                 MapViewPoint p = mapState.getPointFor((INode) m.getMember());
                 if (p.isInView()) {
                     g.draw(new Ellipse2D.Double(p.getInViewX()-4, p.getInViewY()-4, 9, 9));
                 }
 
-            } else if (m.isWay()) {
+            } else if (m.isWay() && viewArea.contains(m.getMember().getBBox())) {
                 GeneralPath path = new GeneralPath();
 
                 boolean first = true;

[taylor.smock]

In 19166/josm:

Fix #23828: Very slow wireframe view with large data set

This occurred since we were drawing every object in every relation (including
nodes of ways) even if those objects were not in view. We fix that by only
drawing objects that are inside the current viewing area.