FreeCADView Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001477 | FreeCAD | Patch | public | 2014-03-16 19:36 | 2014-03-18 10:49 |
| Reporter | mauriz | Assigned To | wmayer | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | linux | OS | Kubuntu | OS Version | 12.04 |
| Product Version | trunk | ||||
| Summary | 0001477: Spaceball becomes uncontrollable for large FreeCAD Documnets on X11 (spacenav) | ||||
| Description | When I load a large Document, my spaceball becomes uncontrollable. I use spacenav on Kubunto 12.04. | ||||
| Steps To Reproduce | Example document: "Twin Cylinder Steam Engine Model" of ppemawm (http://forum.freecadweb.org/viewtopic.php?f=24&t=5718) After a spacball input action, the object continues moving on the screen (up to several seconds). | ||||
| Additional Information | It appears that the window system event queue is flooded: The events are faster generated than they are consumed by FreeCAD. Possible solution for X11 using spacenav: If FreeCAD is busy, the motion data of the incoming events are added up. When FreeCAD is ready, a Spaceball event is generated. To detect a flooding situation, a self addressed event is sent through X11 (see attached patch) At least on my system the patch is working perfectly. Comments and inputs are welcome. Mauriz | ||||
| Tags | No tags attached. | ||||
| FreeCAD Information | |||||
|
|
|
|
|
Great! I'll send a message to one who has a space mouse too. If there it also works we will add it. Many Thanks! |
|
|
Reminder sent to: tanderson69 Hello Thomas, since you also have a space mouse can you please verify this patch? Thanks! |
|
|
I have noticed this problem also, but never looked into it. The patch does fix the continued motion problem. Thanks. Don't we have this problem on other platforms also? It would be nice if we could address this inside Qt or coin somehow instead of the native windowing system. |
|
|
Thanks a lot for the quick feedback. It would be great if someone implemented an operating system independent solution. First I tried also, but I could not come up with a solution without moving the screen updates to a separate thread. This is a task I don't dare to start with... Mauriz |
|
|
Mauriz, I agree with not moving into a threading solution. I am curious as to what you tried. I had to 2 quick thoughts. 1) storing or posting or ignoring values based upon QCoreApplication::hasPendingEvents(). 2) Mostly X ignorant here, but isn't there a timestamp for the xevent generation? Maybe test event generation time vs processing time in view3d handler. I haven't looked into these much, so they might be silly. IMHO: At some point in this event "lag" it wouldn't bother me if the events didn't get accumulated. I find it irritating when the display catches up and all of the sudden the model is off the screen. Don't know if it would be possible to find a "sweet spot" for the cut off between accumulating and ignoring. |
|
|
tanderson69, no idea is silly, ever. 1) QCoreApplication::hasPendingEvents(): Unfortunately, there are other events originating from the window system. QCoreApplication::hasPendingEvents() returns quite often 'true', even if FreeCAD has no problem to catch up with the incoming spacenav events. 2) timestamp: I can't remember to have read something about a timestamp in the documentation, neither for the XClientMessageEvent (spacenav) nor for the XEvent. Did I miss something? Can you give me a hint? IMHO "cut off between accumulating and ignoring": Do you have an example Document where this is a problem? Currently, the feeling of the spaceball navigation is consistent: Lets say, that for a given spaceball manipulation, the model jumps off the screen. Then, with the same manipulation, a model containing a cone only would jump as far ... If we add a cut off, it should be adjustable on the spaceball configuration page (it is a matter of taste). What do you think? Should I prepare an additional patch for that one? |
|
|
I figured as much with the "hasPendingEvents()" It looks like the "timestamp" is a spnav thing not a "X thing"(spnav:event.c:135). Time in between dispatched events. I suppose we could try to keep track of this timing and do something accordingly. not sure it is worth it though. No I don't have a document that shows what I was getting at with the "accumulation vs ignoring". This would be more with long waits and an impatient user. I was thinking that by skipping we could fix that problem also, but not worth too much effort. I lived with it inside UG. Yes your patch provides a consistent movement. I say we merge this and maybe visit the cross platform thing again when somebody on windows starts complaining. Thanks again. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-03-16 19:36 | mauriz | New Issue | |
| 2014-03-16 19:36 | mauriz | File Added: patch.txt | |
| 2014-03-17 08:51 | wmayer | Note Added: 0004462 | |
| 2014-03-17 08:52 | wmayer | Note Added: 0004463 | |
| 2014-03-17 14:38 | tanderson69 | Note Added: 0004464 | |
| 2014-03-17 17:38 | mauriz | Note Added: 0004465 | |
| 2014-03-17 18:27 | tanderson69 | Note Added: 0004466 | |
| 2014-03-17 19:13 | mauriz | Note Added: 0004467 | |
| 2014-03-17 20:17 | tanderson69 | Note Added: 0004468 | |
| 2014-03-18 10:49 | wmayer | Changeset attached | => FreeCAD Master master 490f0417 |
| 2014-03-18 10:49 | wmayer | Assigned To | => wmayer |
| 2014-03-18 10:49 | wmayer | Status | new => closed |
| 2014-03-18 10:49 | wmayer | Resolution | open => fixed |
