Modify

Opened 9 years ago

Closed 9 years ago

#2233 closed defect (fixed)

[PATCH] "Draw mode" instable

Reported by: pieren Owned by: xeen
Priority: blocker Milestone:
Component: Core Version:
Keywords: Cc:

Description

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

Attachments (3)

status_report.txt (20.4 KB) - added by pieren 9 years ago.
status report
Fix Draw Action Settings.patch (831 bytes) - added by xeen 9 years ago.
This fixes the issues with the prefs not working correctly, but doesn't solve the problem at hand
fix cursor bug.patch (6.1 KB) - added by xeen 9 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 Changed 9 years ago by 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?

Changed 9 years ago by pieren

Attachment: status_report.txt added

status report

comment:2 Changed 9 years ago by 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:

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

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by 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

Changed 9 years ago by xeen

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

comment:5 Changed 9 years ago by 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.

comment:6 Changed 9 years ago by 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.

comment:7 Changed 9 years ago by 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.

comment:8 Changed 9 years ago by 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.

comment:9 Changed 9 years ago by xeen

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

comment:10 Changed 9 years ago by 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

comment:11 Changed 9 years ago by stoecker

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

comment:12 Changed 9 years ago by 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.

Changed 9 years ago by xeen

Attachment: fix cursor bug.patch added

comment:13 Changed 9 years ago by xeen

Summary: "Draw mode" instable[PATCH] "Draw mode" instable

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.

comment:14 Changed 9 years ago by stoecker

Resolution: fixed
Status: newclosed

Applied in r1444.

Modify Ticket

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