Slow/laggy panning with a lot of data

[naoliv]

With a lot of data (like in the attached example), JOSM gets slow/laggy when panning the view, with a fair amount of time spent at org.openstreetmap.josm.gui.layer.OsmDataLayer.paint() - org.openstreetmap.josm.gui.MapViewState.getArea():

The impression is that it tries to calculate (or render) something using all the data, instead using only what really needs to be displayed.

Is it possible to improve this somehow?

JOSM:

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2018-10-30 00:47:23 +0100 (Tue, 30 Oct 2018)
Revision:14385
Build-Date:2018-10-30 02:32:55
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (14385 pt_BR) Linux Debian GNU/Linux testing (buster)
Memory Usage: 6144 MB / 6144 MB (5474 MB allocated, but free)
Java version: 11.0.1+13-Debian-2, Oracle Corporation, OpenJDK 64-Bit Server VM
Screen: :0.0 1600x900, :0.1 1280x1024
Maximum Screen Size: 1600x1024
Java package: openjdk-11-jre:amd64-11.0.1+13-2
Java ATK Wrapper package: libatk-wrapper-java:all-0.33.3-21
VM arguments: [-Dawt.useSystemAAFontSettings=gasp]
Dataset consistency test: No problems found

Plugins:
+ OpeningHoursEditor (34535)
+ PicLayer (34544)
+ SimplifyArea (34586)
+ apache-commons (34506)
+ buildings_tools (34572)
+ download_along (34503)
+ ejml (34389)
+ geojson (87)
+ geotools (34513)
+ jaxb (34506)
+ jts (34524)
+ log4j (34527)
+ measurement (34529)
+ merge-overlap (34664)
+ opendata (34698)
+ poly (34546)
+ reverter (34552)
+ tageditor (34560)
+ todo (30306)
+ turnlanes-tagging (272)
+ turnrestrictions (34643)
+ undelete (34568)
+ utilsplugin2 (34506)

[naoliv]

BTW, if I create a new empty layer (leaving this example layer below and enabled (where it's displayed all grey)), moving the map gets fast back again.
Maybe it's related with the style being applied to all the data instead to only what is being drawn at the screen?

[Don-vip]

This performance issue should be in our top priority list I think.
Already reported as #10101 #13952 #14003 #14018 #16128 #16251 #16434 #16696

But not easy to solve...