Modify

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#16128 closed defect (fixed)

Viewport movement and zooming is terribly slow

Reported by: jengelh@… Owned by: team
Priority: major Milestone: 18.12
Component: Core mappaint Version:
Keywords: performance regression Cc: bastiK, stoecker, michael2402, rhardy702@…

Description

Between r7000 and r10526, the draw operation for JOSM nodes and ways went significantly worse to the point of unusability. Java 8 (and later) also play a role, as running 10526 with java7 brings back at least some of the performance.

This seems to concern mostly viewport actions, such as scrolling and zooming the map with the right mouse button/scrollwheel. Moving, for example, a node or polygon around while keeping the viewport unchanged still has acceptable performance.

Since there are no .jar files between 7000 and 10526 on the download server anymore, I cannot narrow it down, and building revisions between that with ant also fails in many ways indistinguishable from magic.

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-07-11 23:04:49 +0200 (Mon, 11 Jul 2016)
Build-Date:2016-07-12 01:31:48
Revision:10526
Relative:URL: ^/trunk

Identification: JOSM/1.5 (10526 en) Linux openSUSE Leap 15.0 Beta
Memory Usage: 273 MB / 1730 MB (189 MB allocated, but free)
Java version: 1.8.0_161-b12, Oracle Corporation, OpenJDK 64-Bit Server VM

Attachments (3)

16128-disable-text-when-moving.patch (6.1 KB ) - added by Don-vip 6 years ago.
02.mp4 (5.1 MB ) - added by Don-vip 5 years ago.
03.mp4 (3.5 MB ) - added by Don-vip 5 years ago.

Change History (60)

comment:1 by jengelh@…, 6 years ago

A screen capture (external camera because josm ought not to share CPU with a screenrecorder too) - http://inai.de/files/16128.mkv (bbox={51.5375538,51.5399828,9.8185874,9.8214769})

comment:2 by stoecker, 6 years ago

All versions are available. Old ones are in Archiv directory.

comment:3 by anonymous, 6 years ago

Meanwhile, I have found that wire mode does not suffer from the performance issues. Through further experimentation, it drills down to the "text:" directive in mapcss files. Removing "text:auto" everywhere restores the performance.
I will try the archives.

comment:4 by jengelh@…, 6 years ago

Last good one: 7380
First bad one: 7391

comment:5 by Don-vip, 6 years ago

Component: CoreCore mappaint
Keywords: performance added

comment:6 by Don-vip, 6 years ago

Cc: bastiK added
Keywords: regression added

@bastiK: it seems to be a regression from r7382:7390, can you please take a look?

comment:7 by bastiK, 6 years ago

I would say it is not a bug but a feature: This is when we introduced more sophisticated label rendering, i.e. text halo for place nodes and text running along the highway. Naturally there is a cost in performance, but I haven't seen it that drastic.

@jengelh: Do you have a fast computer, what kind of CPU?

comment:8 by jengelh@…, 6 years ago

i7-4600U and i5-8250U are the models I have so that is by no means underpowered. Before, I had a Atom N450 and even that ran the then-current version (just around r7200-r7300) good enough. I don't really think I need halo rendering, how could I disable it?

comment:9 by Klumbumbus, 6 years ago

jengelh, please download this old version of the internal style (download at the bottom: raw format) and try in your current setup (josm 10526 or later and Java 8) if this improves the performance significant. (of cause disable the current internal style during the test)

Last edited 6 years ago by Klumbumbus (previous) (diff)

comment:10 by jengelh@…, 6 years ago

Yes, using that revision of the stylesheet in place of the built-in one makes moving the viewport a lot more usable, both with Java 8 and 10 (can't spot a performance difference between the two JRE versions).

in reply to:  8 comment:11 by bastiK, 6 years ago

Replying to jengelh@…:

i7-4600U and i5-8250U are the models I have so that is by no means underpowered. Before, I had a Atom N450 and even that ran the then-current version (just around r7200-r7300) good enough. I don't really think I need halo rendering, how could I disable it?

It is not normal that it takes 1 second to render 10 letters and it would be nice to find the cause for this.

Do you get the extremely slow rendering on both machines independently? If so, the trigger of this problem is bound to be some hardware / software / configuration preference on your side. A possible explanation, that comes to mind is that Java tries to delegate the rendering to the graphics card, but the result is a complete failure.

in reply to:  10 comment:12 by Klumbumbus, 6 years ago

I too had expected that it is rather caused by rendering code or hardware/software configuration. (I can't find such a massive change in the style code itself in r7380:7391) But if using older versions of the style make a difference for you, can you narrow it down to a specific change of the style by testing different old versions with your current JOSM?

comment:13 by jengelh@…, 6 years ago

can you narrow it down to a specific change of the style

yes, the "text:" tag(s) in mapcss, as mentioned earlier in the report.

comment:14 by Don-vip, 6 years ago

Cc: stoecker michael2402 added

We can disable text rendering while moving the map (see patch). It seems to improve drastically the performances without really affecting the rendering: we're not really able to read the text while moving the map. Any objections?

comment:15 by jengelh@…, 6 years ago

Interesting approach. Do you have a .jar of this I could test?

comment:16 by stoecker, 6 years ago

I'd say: Let's test it!

comment:17 by Klumbumbus, 6 years ago

I think we should made this configurable at wiki:Help/Preferences/Display#OSMData (or atleast via advanced preferences), so users which don't have performance issues can disable it. For my taste thats a bit too much "flickering" when moving the map around.

comment:18 by Klumbumbus, 6 years ago

Additional: We could also set the default of setting::highway_labels to false in the mappaint style. I have disabled the display of street names in my josm as it creates too much clutter for me and changing street names is a very seldom task (and in this case I would use Coloured Streets anyway.)

Last edited 6 years ago by Klumbumbus (previous) (diff)

in reply to:  15 comment:19 by Don-vip, 6 years ago

Replying to jengelh@…:

Interesting approach. Do you have a .jar of this I could test?

Please check with download/josm-custom.jar.

in reply to:  17 comment:20 by Don-vip, 6 years ago

Replying to Klumbumbus:

For my taste thats a bit too much "flickering" when moving the map around.

Please test :) When playing with it I find this to be a nice feature. It can be useful to hide labels with a right click, in dense urban areas, it allows to spot more details.

in reply to:  14 comment:21 by michael2402, 6 years ago

@All: When testing such issues, set the mappaint.render.benchmark preference to true, then rendering times will be printed on the console. Phase 1 should be cached and near 0.

I'm at ~200ms with several halo paths on a slow machine (~10 years old, Intel Core 2 Duo @ 1.2GHz)

Replying to bastiK:

A possible explanation, that comes to mind is that Java tries to delegate the rendering to the graphics card, but the result is a complete failure.

You can check this very easily: If CPU load is near 100%, it's a problem on our side (or the way Java renders code).

I'm guessing it has something to do with font rendering.

Replying to Don-vip:

We can disable text rendering while moving the map (see patch). It seems to improve drastically the performances without really affecting the rendering: we're not really able to read the text while moving the map. Any objections?

Move the flag check into the isShowNames() method or use a new shouldRenderNames() method. Otherwise we will easily miss it when moving code around ;-)

comment:22 by Klumbumbus, 6 years ago

Yes, the street labels really make a huge difference in performance, ~4x slower in my test with v13657 attachment:02.mp4

Last edited 5 years ago by Don-vip (previous) (diff)

comment:23 by Klumbumbus, 6 years ago

With patch: performance on move is better, however not on hover. see attachment:03.mp4. without street labels every line is highlighted when moving the mouse over them, with street labels only one of the 10 lines.

Last edited 5 years ago by Don-vip (previous) (diff)

comment:24 by Don-vip, 6 years ago

In 13875/josm:

see #16128, see #16251 - display street labels on z18+, operation very costly on urban areas

comment:25 by Don-vip, 6 years ago

Ticket #16398 has been marked as a duplicate of this ticket.

comment:26 by Don-vip, 6 years ago

Priority: normalmajor

comment:27 by rhardy702@…, 6 years ago

As the author of #16398, I can say removing street labels fixes my problems with zooming, panning, and hovering. I hadn't noticed the problem with hovering specifically. I also can't use Colored Streets, which is very useful when doing addressing.

comment:28 by rhardy702@…, 6 years ago

My hover test: Zoom to two adjacent buildings. Hover over one until highlighted, then switch to the other. The pattern was 3-4 good switches, then 10 seconds or so of high CPU until the next building was highlighted, then a few more good switches, etc.

comment:29 by michael2402, 6 years ago

Are you starting running JOSM from command line (or can you)?

Can you add -verbosegc directly before the -jar parameter?

There should be several messages printed on the console. Can you repeat the test and copy the lines during your test (we don't need the ful log, just the lines that appwared while/around when JOSM was freezing).

comment:30 by anonymous, 6 years ago

I'm starting JOSM with javaws "https://josm.openstreetmap.de/download/josm.jnlp" but it should be cached, so...

tom@sgt:~> java -verbosegc -jar /home/tom/.cache/icedtea-web/cache/3/https/josm.openstreetmap.de/download/josm-tested.jar
[GC (Allocation Failure) 30720K->7919K(117760K), 0.0402744 secs]
2018-06-25 09:01:25.607 INFO: Log level is at INFO (INFO, 800)
[GC (Allocation Failure) 38639K->14286K(148480K), 0.0541838 secs]
[GC (Metadata GC Threshold) 48613K->20441K(148480K), 0.0564061 secs]
[Full GC (Metadata GC Threshold) 20441K->16594K(135680K), 0.2328843 secs]
[GC (Allocation Failure) 78034K->18409K(135680K), 0.0261342 secs]
...

[now I get a working data layer and do the things you asked]

[GC (Allocation Failure) 703996K->134420K(798720K), 0.0804982 secs]
2018-06-25 09:44:57.094 INFO: GET https://api.openstreetmap.org/api/0.6/user/details (get number of unread messages) -> 200 (372 B)
[GC (Allocation Failure) 707746K->144005K(798720K), 0.0576038 secs]
[GC (Allocation Failure) 719493K->143159K(799744K), 0.0515295 secs]
[GC (Allocation Failure) 718647K->149957K(765952K), 0.0617174 secs]
[GC (Allocation Failure) 700269K->150112K(741888K), 0.0496288 secs]
2018-06-25 09:49:57.525 INFO: GET https://api.openstreetmap.org/api/0.6/user/details (get number of unread messages) -> 200 (372 B)
[GC (Allocation Failure) 676448K->151113K(714752K), 0.0647124 secs]
[GC (Allocation Failure) 654409K->151158K(687104K), 0.0548166 secs]

[It's a bit hard to associate the above with specific actions, but I associate the following with one highlighting delay of about 5 seconds...]

[GC (Allocation Failure) 632950K->151214K(667136K), 0.0469033 secs]

I'm going keep JOSM running until I can put it to serious use....

comment:31 by rhardy702@…, 6 years ago

However, I can get such a message with street labels and no apparent highlighting problems.

comment:32 by rhardy702@…, 6 years ago

I meant "No street labels..."

comment:33 by anonymous, 6 years ago

Those numbers are perfectly fine.

This rules out that a GC cycle / compaction phase is causing your delays - we need to find the cause somewhere else.

comment:34 by michael2402, 6 years ago

Sorry, that last comment was by me - I was on a mobile and just wanted to stop you from digging more if there is noting there ;-)

This option enables the garbage collector statistics output. Garbage collection is one of the causes for a freeze in Java. Even with the modern garbage collectors, there are situations where the garbage collector cannot optimize the collection and needs to do a full swipe - which can let your VM pause for several seconds. You can see how long garbage collection freezes your program by turning on the stats. In your case, the garbage collector only freezes JOSM for around 0.05 seconds which you should not even notice ;-)

comment:35 by rhardy702@…, 6 years ago

I gathered. Also, the association is very weak. It was the only message that occurred during the 5 second freeze, but I did several other things during that period, gave JOSM focus, passed over several other ways both before and after the test, gave focus back to Konsole, etc.

comment:36 by rhardy702@…, 6 years ago

And, to reiterate a point made in #16398, while using LiveGPS JOSM can get behind, and then spend multiple minutes at high CPU gradually updating position until it becomes current and usable again. I've since observed a position marker creeping along, updating every 15 seconds or so until it became current, minutes after I had stopped moving.

comment:37 by Don-vip, 6 years ago

Milestone: 18.06

comment:38 by Don-vip, 6 years ago

In 13987/josm:

see #16128 - don't display names while moving the map. Improves dragging performance greatly.

comment:39 by Don-vip, 6 years ago

Milestone: 18.0618.07

That will be all for this month.

comment:40 by Don-vip, 6 years ago

In 13989/josm:

see #16128 - display names by default

in reply to:  40 comment:41 by Klumbumbus, 6 years ago

Replying to Don-vip:

In 13989/josm:

see #16128 - display names by default

If I understand correct this means that by default nothing changes, but one can enable the text hiding by setting doSlowOperations to false?

If so this doesn't work for me. With r13996 text is hidden an there is no doSlowOperations key in the preferences.

comment:42 by Don-vip, 6 years ago

The last commit was only for unit tests and does not have any operational impact.

The change I made is only to hide labels while dragging the map. It does not change the default behaviour of displaying labels along ways, nor add any user preference entry to customize this behaviour. It's so slow I don't think anyone would want to restore the previous behaviour.

Last edited 6 years ago by Don-vip (previous) (diff)

comment:43 by Klumbumbus, 6 years ago

OK. Well the "on off flickering" of text while moving the map is not yet really my friend, but I guess I get used to it. (On small datasets and without streets labels (my most use case) I didn't notice such a big performance loss.)

comment:44 by Don-vip, 6 years ago

I can make an expert option if you want. Maybe you can try to restore street labels now?

comment:45 by Don-vip, 6 years ago

Documented in Help/MapView:


in reply to:  44 ; comment:46 by Klumbumbus, 6 years ago

Replying to Don-vip:

I can make an expert option if you want.

If it is not too much work...
I know we don't want a user setting for every single bit of the software, but this change is to me one of the more significant ones.

Maybe you can try to restore street labels now?

I don't understand what you mean.

in reply to:  46 ; comment:47 by Don-vip, 6 years ago

Replying to Klumbumbus:

If it is not too much work...

It's not :)

Maybe you can try to restore street labels now?

I don't understand what you mean.

I meant I understand you disabled the rendering of street names in the default map paint style settings, as this was the main performance penalty. With this change you can restore the option to its default value; it will still be slow on highlight and zoom, but not when dragging the map.

in reply to:  47 comment:48 by Klumbumbus, 6 years ago

Replying to Don-vip:

Replying to Klumbumbus:

Maybe you can try to restore street labels now?

I don't understand what you mean.

I meant I understand you disabled the rendering of street names in the default map paint style settings, as this was the main performance penalty.

No, in general I didn't notice a performance loss during "daily mapping activities". I disabled the street labels cause they "disturb" me in most situations. And with the often on and off of labels they become even more distracting.

comment:49 by anonymous, 6 years ago

Note: "Hide while dragging" is insufficient for the viewport to keep up while using LiveGPS on my HP2000 laptop with AMD E450 CPU.

I tested with a square circa 16 km2 area with full data. It keeps up while zoomed out, or while zoomed in but with the data area out of the viewport. (In other words, while I was driving elsewhere.)

It bogged down and got behind with street labels fully displayed, and faithfully marched through every 1/second GPS update at the rate of one every 15 seconds. While in that state, it was responsive to menu clicks and right clicks--after about 30 seconds--and it eventually got caught up after I simply stopped moving.

I get the same behavior with Colored Streets enabled.

comment:50 by Don-vip, 6 years ago

In 14060/josm:

see #16128 - add new advanced property mappaint.hide.labels.while.dragging

comment:51 by Don-vip, 6 years ago

Milestone: 18.0718.08

That will be all for this month. I'll add a GUI setting next month.

comment:52 by Don-vip, 6 years ago

Milestone: 18.0818.09

comment:53 by Tom Hardy <rhardy702@…>, 6 years ago

Cc: rhardy702@… added

comment:54 by Don-vip, 5 years ago

Milestone: 18.0918.10

comment:55 by Don-vip, 5 years ago

Milestone: 18.1018.11

comment:56 by Don-vip, 5 years ago

Milestone: 18.1118.12

comment:57 by Don-vip, 5 years ago

Resolution: fixed
Status: newclosed

In 14492/josm:

fix #16128 - add new GUI setting for mappaint.hide.labels.while.dragging

by Don-vip, 5 years ago

Attachment: 02.mp4 added

by Don-vip, 5 years ago

Attachment: 03.mp4 added

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. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.