Delayed line drawing/slow JOSM

[jumat@…]

I have already opened a ticket concerning this problem, see here a couple of weeks before. This was closed.
Under the current version of JOSM (13878) basicly the same problem, that is described there, occurs. The delay, when drawing lines and setting a point is getting worse the longer I'am working with JOSM. Especially, after uploading the data to OSM the performance goes down.
In the ​Austrian OSM forum several user have observed the same under various platforms (Mac, Windows, Linux) - I have observed it under Mac and Windows.

What steps will reproduce the problem?

1. download an aera of approx. 10x10km
2. draw lines, tag them up to approx. 800-1200 revised/created objects
3. upload them
4. draw and revise another 500 objects, upload them
5. every time I'am uploading the data, JOSM became slower. The delay of line drawing becomes visible.

What is the expected result?

To get JOSM working faster and reduce the delay in line drawing effectively and permanent.

What happens instead?

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: 2018-05-31 00:51:20 +0200 (Thu, 31 May 2018)
Build-Date:2018-05-30 22:58:01
Revision:13878
Relative:URL: ^/trunk

Identification: JOSM/1.5 (13878 de) Mac OS X 10.13.5
OS Build number: Mac OS X 10.13.5 (17F77)
Memory Usage: 1182 MB / 2731 MB (910 MB allocated, but free)
Java version: 1.8.0_171-b11, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: Display 441084945 2560x1080
Maximum Screen Size: 2560x1080
VM arguments: [-Djava.library.path=/private/var/folders/mq/zwtfhdb533d13ylzfqpbjrfc0000gn/T/AppTranslocation/2A85D6F4-30C3-48C0-888E-E45DDABB49D4/d/JOSM.app/Contents/MacOS, -DLibraryDirectory=${HOME}/Library, -DDocumentsDirectory=${HOME}/Documents, -DApplicationSupportDirectory=${HOME}/Library/Application Support, -DCachesDirectory=${HOME}/Library/Caches, -DSandboxEnabled=false, -Dapple.laf.useScreenMenuBar=true, -Dcom.apple.macos.use-file-dialog-packages=true, -Dcom.apple.macos.useScreenMenuBar=true, -Dcom.apple.mrj.application.apple.menu.about.name=JOSM, -Dcom.apple.smallTabs=true]
Dataset consistency test: No problems found

Plugins:
+ austriaaddresshelper (1525848529)
+ buildings_tools (34212)
+ continuosDownload (68)
+ contourmerge (1032)
+ editgpx (34109)
+ utilsplugin2 (34221)

Map paint styles:
+ https://pasharm.github.io/New_basic_style_for_JOSM/New_basic_style.mapcss

Last errors/warnings:
- W: Unable to convert property color to type class java.awt.Color: found # of type class java.lang.String!
- W: Unable to convert property color to type class java.awt.Color: found # of type class java.lang.String!
- W: Unable to convert property color to type class java.awt.Color: found # of type class java.lang.String!
- W: Unable to convert property color to type class java.awt.Color: found # of type class java.lang.String!
- W: Unable to convert property color to type class java.awt.Color: found # of type class java.lang.String!
- W: Unable to convert property color to type class java.awt.Color: found # of type class java.lang.String!
- W: Unable to convert property color to type class java.awt.Color: found # of type class java.lang.String!
- W: Unable to convert property color to type class java.awt.Color: found # of type class java.lang.String!
- W: Unable to convert property color to type class java.awt.Color: found # of type class java.lang.String!
- W: Unable to convert property color to type class java.awt.Color: found # of type class java.lang.String!

[Don-vip]

I can notice a slow drawing with a lot of data displayed because we invalidate the data layer at each mouse movement in DrawAction.redrawIfRequired. Unlikely that uploads have any performance effect (there is just more data). We should mark the primitives we want to rerender, instead of repainting the entire layer. Michael did you ever work on this?

[michael2402]

Replying to Don-vip:

I can notice a slow drawing with a lot of data displayed because we invalidate the data layer at each mouse movement in DrawAction.redrawIfRequired. Unlikely that uploads have any performance effect (there is just more data). We should mark the primitives we want to rerender, instead of repainting the entire layer. Michael did you ever work on this?

Yes, I spent a lot of work on this.

There are several things that are already implemented:
(1) We have much more fine-graned invalidation (per-layer) than we had before. That way, hidden layers should not cause a redraw.
(2) In many places, the rendering code is prepared to use the repaint area and handle it differently from the view area. That way, we can re-render parts of the view without the labels jumping. I changed the renderer interface to pass on both areas.

The problem is with determining the area that should be re-rendered. Even moving a node on one side of the screen may affect the rendering on the other side of the screen if there is a way / area connected to it. Style invalidation in MapCSS is already done by us. Even an unconnected node can have a label that has a width of more than 100px, so we would need to know the current area of the label and the area the label would cover afte repaint.

The next problem is that once you determined that area, you cannot re-render a single primitive. You need to re-render everything that is in that area. This is because Java2D does not render the view as a vector graphic (as opposed to OpenGL)

My OpenGL port is a bit abandoned since I do not have the time required to maintain / update it. Rendering changes there was really fast, since the style changes are already tracked and all unchanged primitives can be taken from VBO objects that reside in the graphics card. So hovering performance was improved. Updating the code to current JOSM would take me ~1-2 months full time.

The place where I got problems there was the view movement. The moment you move the view in JOSM, label placements may change. This requires quite some complex viewport state tracking.

I did a lot of changes to JOSM core the last two years in those areas so that the core supports a better change tracking and a more universal view coordinate conversion.

One thing I already experimented with was tiled rendering (e.g. split the view into 4 parts, render them). Turns out that except for really dense situations and using many (4+ cpus), the performance won't imrpove because you can only use one OpenGL accelerated painter and the other ones need to paint to buffered graphics in memory which then need to be copied to the graphics card. We already do something like this for imagery tiles if they get filtered, you can see the performance differences there by simply removing the condition that tests if the filter is a no-op in any filter ;-)

[Don-vip]

Replying to michael2402:

Yes, I spent a lot of work on this.

Thanks for the detailed explanation. I'll see what I can do.

My OpenGL port is a bit abandoned since I do not have the time required to maintain / update it.

Can you please transfer it to the JOSM organization?

[jumat@…]

Yesterday I upgraded to latest JOSM 13996. Line drawing/mapping become worse and worse.
I download an aera of approx. 5x5km. 1st click & 1st point of drawing is already signifiicantly delayed. I observed, that Popups for Tagging (right side bar in JOSM > attributes > add) are also delayed when clicking. After approx. 400-500 newly drawn points, the delay from click-to-click is around 1-1,5 seconds.
My JOSM has 2GB RAM memory, but used just around 50MB, so approx. 5%. RAM-memory seems not be the problem.

[jumat@…]

Another question: May I change several Java-settings to enhance the performance of JOSM? If so, which ones? Any hint?

[Don-vip]

Replying to jumat@…:

Yesterday I upgraded to latest JOSM 13996. Line drawing/mapping become worse and worse.
I download an aera of approx. 5x5km.

Please share the JOSM session file where you notice the problem + a screenshot when it occurs.

[jumat@…]

Session file attached to this post.
Currently, the delay from click-to-click is around 1-1,5 seconds.

[Don-vip]

I still can't reproduce with the default zoom level (10m). Can you please share a screenshot of the area and zoom level where you notice the problem, using the attached session file?

[jumat@…]

2 days ago I have updated Java and upgraded JOSM its latest version. Now, all my troubles concerning this issue are gone. JOSM works as it intended to work. I'am very happy with the new situation and the timeless response of line drawing function.

[Don-vip]

Removing from milestone then. We should still implement ideas described in #comment:4 and #comment:5

[taylor.smock]

The opengl port referenced in comment:4 is located at ​https://github.com/michaelzangl/josm-plugin-opengl .

One thing I already experimented with was tiled rendering (e.g. split the view into 4 parts, render them).

I've been experimenting with this as well (see #11487), and the one killer feature with rendering to tiles is that the UI isn't blocked if there is a lot of data on screen. I haven't gone as far as multithreading the rendering, since I ran into some CCE issues. But we do have to invalidate tiles with selected/highlighted data, since they need to be redrawn.