Modify

Opened 3 months ago

Closed 3 months ago

Last modified 3 months ago

#17095 closed enhancement (fixed)

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

Reported by: jumat@… Owned by: team
Priority: normal Milestone: 18.12
Component: Core mappaint Version:
Keywords: template_report performance Cc: bastiK

Description

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!

Attachments (4)

17095-area.osm.bz2 (592.7 KB) - added by GerdP 3 months ago.
17095-VisualVM.PNG (133.8 KB) - added by GerdP 3 months ago.
CPU sampling when mouse is moving near 47.87778, 14.44582
17095.patch (1.2 KB) - added by GerdP 3 months ago.
17095-v2.patch (3.7 KB) - added by GerdP 3 months ago.
new method computeFill() for StyledMapRenderer

Download all attachments as: .zip

Change History (39)

comment:1 Changed 3 months ago by GerdP

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

comment:2 Changed 3 months ago by jumat@…

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

comment:3 Changed 3 months ago by 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

comment:4 Changed 3 months ago by 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.

comment:5 Changed 3 months ago by 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.

comment:6 Changed 3 months ago by 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.

comment:7 Changed 3 months ago by jumat@…

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

comment:8 Changed 3 months ago by 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.

comment:9 Changed 3 months ago by jumat@…

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

comment:10 Changed 3 months ago by 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.

comment:11 Changed 3 months ago by 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.

comment:12 Changed 3 months ago by Don-vip

Component: CoreCore mappaint
Keywords: performance added

Changed 3 months ago by GerdP

Attachment: 17095-area.osm.bz2 added

Changed 3 months ago by GerdP

Attachment: 17095-VisualVM.PNG added

CPU sampling when mouse is moving near 47.87778, 14.44582

comment:13 Changed 3 months ago by 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.
CPU sampling when mouse is moving near 47.87778, 14.44582

comment:14 Changed 3 months ago by jumat@…

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

comment:15 Changed 3 months ago by GerdP

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

comment:16 Changed 3 months ago by jumat@…

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

comment:17 Changed 3 months ago by 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.

comment:18 Changed 3 months ago by jumat@…

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

comment:19 Changed 3 months ago by 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.

comment:20 Changed 3 months ago by 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.

comment:21 Changed 3 months ago by 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...

Changed 3 months ago by GerdP

Attachment: 17095.patch added

comment:22 Changed 3 months ago by GerdP

Summary: slow JOSM - delayed line drawing[Patch] slow JOSM - delayed line drawing

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.

comment:23 Changed 3 months ago by 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.

Last edited 3 months ago by GerdP (previous) (diff)

comment:24 Changed 3 months ago by 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.

Changed 3 months ago by GerdP

Attachment: 17095-v2.patch added

new method computeFill() for StyledMapRenderer

comment:25 Changed 3 months ago by GerdP

Cc: bastiK added

comment:26 Changed 3 months ago by GerdP

In 14557/josm:

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

comment:27 Changed 3 months ago by GerdP

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

comment:28 Changed 3 months ago by GerdP

Resolution: fixed
Status: newclosed

comment:29 Changed 3 months ago by jumat@…

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

comment:30 Changed 3 months ago by GerdP

Download the latest version from https://josm.openstreetmap.de/ (and make sure to use it if you start josm with a script)
once that 14557 or newer is available.

Last edited 3 months ago by GerdP (previous) (diff)

comment:31 Changed 3 months ago by 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.

comment:32 Changed 3 months ago by 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

comment:33 Changed 3 months ago by GerdP

Milestone: 18.12
Summary: [Patch] slow JOSM - delayed line drawing[Patch] slow JOSM when map style uses fill-image

comment:34 Changed 3 months ago by 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.

comment:35 Changed 3 months ago by 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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
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.