[Patch] slow JOSM when map style uses fill-image

[jumat@…]

What steps will reproduce the problem?

1. download areas with approx. 10km2 on a Mac
2. upload a changeset and start drawing lines etc. again
3. the longer you are working with JOSM, the slower the lines are drawn and the delay from a set point to other increases

What is the expected result?

reduce/delay this delay.

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-11-28 01:09:01 +0100 (Wed, 28 Nov 2018)
Build-Date:2018-11-28 00:26:41
Revision:14460
Relative:URL: ^/trunk

Identification: JOSM/1.5 (14460 de) Mac OS X 10.14.1
OS Build number: Mac OS X 10.14.1 (18B75)
Memory Usage: 1141 MB / 1820 MB (489 MB allocated, but free)
Java version: 1.8.0_191-b12, 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/3587D234-BD8D-4CBA-B958-97A33E6E0CFB/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 (57)
+ buildings_tools (34724)
+ continuosDownload (82)
+ contourmerge (v0.1.3)
+ utilsplugin2 (34506)

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!

[GerdP]

I can reproduce this problem with your Mappaint style, but not with the Josm Default style.

[jumat@…]

Ok, so it's a problem of the style? What can I do to change this?

[GerdP]

Well, you can select a different style or you may try to contact the author of the style:
​https://github.com/pasharm/New_basic_style_for_JOSM/issues

[jumat@…]

Thanks for your help - I've opened an issue on github to solve this problem. Because, it doesn't occurs first time. More or less, it's a problem for more than 1 year now.

[GerdP]

I've just noticed that there is a pull request from the Josm team since April, so maybe this style is no longer maintained.

[Don-vip]

This map paint style is notoriously slow. I don't know if it comes from a bad usage of our features or if it triggers a performance problem in JOSM core.

[jumat@…]

What can I do to solve this issue? Just deactivate the Map style? Unfortunenatly this map style is really good for mapping.

[GerdP]

Maybe this helps to find the bottleneck:
Most of the time is spent in sun.java2d.SunGraphics2D.clip() called by org.openstreetmap.josm.data.osm.visitor.paint.StyledMapRenderer.drawArea()
This is also true for the default style, but it seems that the new style needs more clipping.

[jumat@…]

@ GerdP
What can I do as a "common User"? Or is your issue related to developers?

[GerdP]

As a common user you can select the common style or maybe another one which is not that slow.
You may also try to change the New_basic_style.mapcss. I see that it uses circles for the nodes while the default style uses squares. Might be the reason for the slow performance.

[GerdP]

Indeed, the change from circle to square seems to improve performance quite a lot, at least on my machine.
You can try it, simply download the file, change all occurences of circle to square and add it as a new style.

[GerdP]

CPU sampling when mouse is moving near 47.87778, 14.44582

[GerdP]

I've attached a sample file that shows very well the problems. It just depends on the data, no need to change or upload data.
The area contains some complex forest MP. Using the new style moving the mouse near 47.87778, 14.44582 while zoomed out the CPU is very busy. The same happens when you zoom in to draw e.g. a farmyard.

[jumat@…]

Great. Thanks for your explainatins, GerdP. What can I do now to improve the speed?

[GerdP]

Did you already try what I told you in comment:11?

[jumat@…]

No, because I do not know, where to change this (circle > square).

[GerdP]

1) Download the source file ​https://pasharm.github.io/New_basic_style_for_JOSM/New_basic_style.mapcss
2) Open it in an editor, search + replace circle -> square
3) In JOSM, use View -> Map Paint Styles -> Map paint preferences
4) Press the + Button on the upper right and fill the popup with the modified style and name "test".
5) Make sure that only test is activated and close the dialog with OK

I don't know yet why this improves performance, I think that's something we JOSM devs have to find out.

[jumat@…]

Yes, it worked out. Should I activate only this new stylesheet or also "JOSM Standard"?

[GerdP]

See 5)
Unfortunately I cannot reproduce the performance improvement today working on my PC. Maybe I made an error yesterday. So, if you don't see an aprovement forget this hint and use the Josm default style for now.

[GerdP]

OK, I think now I found a better work around:
Download the file again and remove the two lines containing the string wood2.png
besides that do the same as in 3)..5)
Now it's clear to me why this style is so slow. Rendering images takes more time than rendering a fill colour, and that is what we see in the VisualVM screenshot.

[GerdP]

@team: I think the problem here is that we clip the complex multipolygon each time the mouse is moved. It would be much faster to remember the clipped polygon as long as the user actions don't change it and the visible area is not changed or maybe split the rendered MP into smaller areas.
Another idea: Is it really needed to render the full screen when the mouse moves a single pixel? Would it be possible to split the screen into maybe 10x10 rectangles and render only the one that contains the cursor or objects which are changed by the user actions like highlighted objects, selected objects etc.? Another point that bothers me: Frequent re-rendering is also enabled when you open e.g. the search dialog. I see no need for that.
Just some ideas, I have no experience with rendering so far...

[GerdP]

I wondered why the clipping is implemented in two ways depending on the use of an img to fill an area.
The attached small patch uses the same steps and it improves the performance drastically. I causes differences but I don't think to the worse. The patch is just a quick hack, if there is no complain I'd put the similar steps into a new methdod.

[jumat@…]

Thanks a lot, GerdP for trying to solve this long-time running issue.

So, should I revise the downloaded mappaint style according to your comment:20 or will to implement further revision and I should wait for it?
I guess, this won't affect only my computer, but also other users will have the same problem using this mapstyle.

[GerdP]

As I said my experience with rendering is small, so my patch might not work in all cases and you probably don't want to compile your own JOSM with my patch, so please be patient until this ticket is closed.
The work-around described in comment:20 works when the multipolygon is a natural=wood or landuse=forest, there are more lines where a picture is used to fill a shape (search for fill-image), all those are nice to have but slow down the rendering without my patch.

[GerdP]

new method computeFill() for StyledMapRenderer

[GerdP]

In 14557/josm:

see #17095 Use same method for partial fill with colour or picture

[GerdP]

No complains. If all unit tests are passed I'll close this as fixed.

[jumat@…]

Ok, and how can I - as a common user - benefit? Is there any download file available? Please advise.

[GerdP]

Download the latest version from https://josm.openstreetmap.de/ (and make sure to use it if you start josm with a script)

[jumat@…]

On this site (josm.openstreetmap.de) I just see the current, installed JOSM 14660 to download.
"and make

sure to use it if you start josm with a script)

"
What does that mean in detail? When I download JOSM in the past, I open the jar-file and JOSM starts. Which script is required? Sorry for my confusion, but I cannot follow this instruction.

[GerdP]

Maybe scroll down a bit to find a link to josm-latest.jar. You can start JOSM like you do, but many people use a script to set some options, for example the max memory for the java run time (maybe -Xmx2G). I use a script that checks if a new "latest" version is available and - if so - downloads it before starting JOSM.
In case you don't find the link to the jar: https://josm.openstreetmap.de/josm-latest.jar

[jumat@…]

This new release of JOSM works fine - now I can map first time ever in HUN, which has been a problem due to the massive delay in line drawing. In HUN the data base is worse than in Austria (lots of multipolygons, very large and many members) and this caused rapid lack of performance for JOSM.

[GerdP]

Great! Thanks for the feedback. I still see room for improvements when it comes to really complex multipolygons. Sometimes it seems that I see a massive slowdown once a complex MP is complete. I'll have a closer look again during the next weeks.