Attachments (0)
Change History (8)
comment:1 by , 15 years ago
Owner: | changed from | to
---|
comment:2 by , 15 years ago
Summary: | josm 3128, 3129 extremely slow and laggy → josm >= 3116 extremely slow and laggy |
---|
comment:3 by , 15 years ago
Is it slow (ie full cpu usage) or laggy (it takes some time before layer is refreshed)?
follow-up: 5 comment:4 by , 15 years ago
It's possible that it's slow because of missing double buffering (which was useless on linux, but might be different on FreeBSD). Plese try customized josm from http://jttt.110mb.com/josm-custom.jar and let me know if it makes any difference.
comment:5 by , 15 years ago
Replying to jttt:
It's possible that it's slow because of missing double buffering
If that's the case, you might see it draw one line after the other. Normally it should display everything at once.
comment:6 by , 15 years ago
Plese try customized josm from http://jttt.110mb.com/josm-custom.jar and let me know if it makes any
difference.
This jar works fine, with no lags. Thanks.
Is it slow (ie full cpu usage) or laggy (it takes some time before layer is refreshed)?
It is laggy. The CPU usage is not full. The java process state is usually "ucond", which means waiting on userland mutex.
comment:7 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I have made a a binary search through SVN revisions, and found that the r3116 is the one to blame:
r3116 | jttt | 2010-03-11 23:01:49 +0300 (чт, 11 мар 2010) | 1 line
Reuse offscreenBuffer if layers didn't change
Now I need to stick to 3115, because newer versions are almost unusable.