[PATCH] "Draw mode" instable

[pieren]

I updated my JOSM to ver. 1437 and noticed some instability after a
while of intensive editing. When I create ways after, let say, 100 or
200 nodes, the cursor disappears in the "draw" mode only. Then all
windows look strange. Hopefully I was able to upload my changes but
many dialogs do not allow a click on the "ok" button.
Note that I work in the "wireframe" view, disalbling the rubber-bandm
but I'm not sure it is playing a role here.
This problem appeared somewhere between rev. 1406 and 1437

[xeen]

Hmm… my first guess would be JOSM is out of memory, at least your description matches my experience here. On the other hand, I wouldn't know why the highlighting would cause this. It's only a boolean attached to each node/way/relation so it's likely less than 1 MB. Also, none of the changes made to the drawing code should affect whole JOSM.

1437 should have the Status Report function. If this happens again, please go to Help -> Status Report and paste the contents here (if it still works that is…). Could you also post them now so I can look at your settings etc. to get more insight on what might be the problem… were you maybe using the WMS Plugin while this happened?

[pieren]

status report

[xeen]

I've looked at the patches in the checkin range and excluded those that don't seem to be connected to this at all. This leaves me with:

• [1409]
• [1412]
• [1415]
• [1423]
• [1430]

It would be a great help if we could narrow this down. Can you reproduce the problem?

[pieren]

As you can see in the report, it's not a memory issue. I think I went to the corrupted display when I scrolled the zoom (in/out) within the "Draw" mode. The zoom seems to refresh the position of the rubber-band which is not the case otherwise.
About the rubber-band, the preference setting is ignored since the parameter "draw.helper-line" is combined with "draw.target-highlight" which is not configurable in the dialogs.

[xeen]

My test with 35 000 created nodes yielded nothing, but it's not comparable with real mapping anyway. Maybe it's related to Java 5 vs Java 6. I'll downgrade and see if I can reproduce the problem.

I'll look into the helper line issue, but I doubt it's the cause for this. At most, this gets it drawn when it actually shouldn't be drawn but it really shouldn't hang JOSM

[xeen]

This fixes the issues with the prefs not working correctly, but doesn't solve the problem at hand

[pieren]

I cannot say exactly what is the action going to this state. To reproduce it, I have to draw a couple of new ways, moving the mouse pointer around, mixing small and middle size segments and suddently the "draw" pointer disappears. By moving the mouse, the normal windows cursor reappears but if I stop to mode, the mouse pointer disappears completely. If I switch to the "select" mode or "delete" mode, the cursor is normal. But if I open a window, the mouse pointer disappers again, the window is not complete and some buttons are invisible until I mode the invisible cursor on it.
Of course, for the test, I move and click the mouse very quickly but it's also happening in the normal activities but it takes a bit more time to see it.
It seems that the problem is related to the new feature changing the mouse pointer quite often... but not for sure.

[xeen]

Try this build:
​http://mathphys.fsk.uni-heidelberg.de/~stefan/josm/josm-nocursor.jar

It's not possible to completely stop the cursor re-writing flipping the pref as it still resets back to the old one. This build has all "special" cursor parts commented out. Please try and see if it fixes the problem. It also has my previous patch applied, so the helper line bug should be gone as well.

[pieren]

Yes, it's stable now. So the problem is related to the mouse pointer changing very often.

BTW, the parameter "alaPotlatch" is ignored. Potlatch style is always enabled. But that's another story.

[xeen]

Ah, I am quite relieved we found the root of this issue so fast. I'll see what I can do about fixing this, I'm not sure where the problem comes from. Can I ping you for new versions to test?

About Potlatch style: It works here. Are you sure you're not confusing Potlatch style with something else? Potlatch style means you can click on an empty space in select mode and it will automatically start drawing. Additionally, when finishing drawing (clicking last node again or double clicking) it will switch back to select mode.

While double clicks still stop drawing the current way, it doesn't switch to select mode or automatically from select mode to draw mode though.

[xeen]

Last paragraph refers to "normal" or "non-Potlatch" style

[xeen]

Try this build: ​http://mathphys.fsk.uni-heidelberg.de/~stefan/josm/josm-fixcursor.jar

I've done some changes, please let me know if they fix the cursor problem. As before it contains the preferences fix and I also fixed cases where the mouse had to be moved before cursor/highlighting would be updated.

Note that the amount of "set cursor" calls have been reduced dramatically; it now checks before blindly setting the cursor. However, this might hide the issue only: Less calls also means less chance reproducing the problem. I.e. it might still occur after, say half an hour. So if this seems to work, continue using the build in case the patch only fixed the symptoms.

Thanks!
xeen

[stoecker]

Helperline fix applied. Blame on me - I have seen this during checkin procedure, but forgot to fix it.

[pieren]

Ok, I tried your latest version and cannot reproduce the mouse pointer disappearing even if I moved and click and zoomed intensively during 5 minutes.

[xeen]

The patch that was in the testbuild. It saves the cursors in local variables and loads them only once. Cursors are only switched when the current is different. Setting the cursor is now wrapped in an EventQueue, this might be unnecessary. Patch also fixes some re-draw problems where cursor/highlighting would lag behind helperline.

[stoecker]

Applied in r1444.