Hallo Robert, Am 20.09.2017 um 15:48 schrieb Robert Helling: > Hi, > >> On 20. Sep 2017, at 15:01, Stefan Fuchs <[email protected] >> <mailto:[email protected]>> wrote: >> >> Maybe we should indeed disable most of the planner UI elements while >> the calculations are performed and enable them again after they are >> finished. I would love to test this but once again recognized that I >> have almost no object oriented programming skills at all... :-( > > no, the planning should happen in a background thread. [...]. Plus, it > shouldn’t be a lock, each new invocation of a planner thread should > kill all previous ones. > Yes, you are for sure right that this would be the perfect solution.
> Yesterday, I sent a pull request for a switch to turn of the > computations of the variations. With that switch set to off, do you > still think the responsiveness of the planner is worse than before? In > that case, a bit more profiling work could improve that situation. > > [...] I immediately tested this as soon as the PR was there :-) Yes, unfortunately even with variations turned off the responsiveness of the planner is a little bit worse than before. It is not worse in a way that I would complain about the plan calculation time itself but unfortunately the difference is enough to reveal this issue with the QSpinBox UI elements (Windows10, my PC (!) - can be different elsewhere). Nevertheless I'm absolutely not blaming your change in the algorithm for anything and this has also one specific reason: I already once saw the QSpinBox issue in v4.6.4 or even before on my (slow) Notebook. So as I was saying already at the very beginning: Your change only revealed the issue. To be more precise: Current master release build, variations off on my desktop PC running Win10: QSpinBox issue (double increment/decrement) always present 4.6.4 on my desktop PC running Win10: No QSpinBox issue 4.6.4 (or older) on my Atom based Notebook running Win10: QSpinBox issue (double increment/decrement) sometimes present Than means for me it's not really top priority to try to improve calculation time but it is important to fix the issue with the QSpinBox elements. The UI elements should work correctly no matter how long the calculation takes. For me there are still two viable options: Your solution with the background thread or my proposal with disabling the QSpinBox UI elements while calculation is running. My solution for sure has the disadvantage that the user has to wait for the end of the calculation after each QSpinBox change. It for sure also only work together with disabling keyboard tracking for all QSpinBox elements. That means user has to type, press enter or move focus to another UI item and then calculation will start. Today calculation is triggered after each key-press that changes the value. Best regards Stefan -- Stefan Fuchs E-Mail: [email protected] <mailto:[email protected]>
_______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
