Summer work on the planner - Issue with QSpinBox planner preferences

[Stefan Fuchs]

Hallo Robert,

Am 20.09.2017 um 15:48 schrieb Robert Helling:
> Hi,
>
>> On 20. Sep 2017, at 15:01, Stefan Fuchs <sfuchs at gmx.de
>> <mailto:sfuchs at gmx.de>> 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: sfuchs at gmx.de <mailto:sfuchs at gmx.de>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20170920/86e0ebe1/attachment.html>