<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hallo Robert,<br>
</p>
Am 20.09.2017 um 15:48 schrieb Robert Helling:<br>
<blockquote type="cite"
cite="mid:8AF3148A-B3EA-49BA-81B4-265C1E6788DA@atdotde.de">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
Hi,
<div class=""><br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 20. Sep 2017, at 15:01, Stefan Fuchs <<a
href="mailto:sfuchs@gmx.de" class=""
moz-do-not-send="true">sfuchs@gmx.de</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class=""><span style="font-family: Helvetica;
font-size: 12px; font-style: normal; font-variant-caps:
normal; font-weight: normal; letter-spacing: normal;
text-align: start; text-indent: 0px; text-transform:
none; white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color:
rgb(255, 255, 255); float: none; display: inline
!important;" class="">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... :-(</span><br
style="font-family: Helvetica; font-size: 12px;
font-style: normal; font-variant-caps: normal;
font-weight: normal; letter-spacing: normal; text-align:
start; text-indent: 0px; text-transform: none;
white-space: normal; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color:
rgb(255, 255, 255);" class="">
</div>
</blockquote>
</div>
<br class="">
</div>
<div class="">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. </div>
<div class=""><br class="">
</div>
</blockquote>
Yes, you are for sure right that this would be the perfect solution.<br>
<br>
<blockquote type="cite"
cite="mid:8AF3148A-B3EA-49BA-81B4-265C1E6788DA@atdotde.de">
<div class="">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.</div>
<div class=""><br class="">
</div>
[...]</blockquote>
I immediately tested this as soon as the PR was there :-)<br>
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.<br>
<br>
To be more precise:<br>
Current master release build, variations off on my desktop PC
running Win10: QSpinBox issue (double increment/decrement) always
present<br>
4.6.4 on my desktop PC running Win10: No QSpinBox issue<br>
4.6.4 (or older) on my Atom based Notebook running Win10: QSpinBox
issue (double increment/decrement) sometimes present<br>
<br>
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.<br>
For me there are still two viable options: <br>
Your solution with the background thread or my proposal with
disabling the QSpinBox UI elements while calculation is running.<br>
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.<br>
<br>
Best regards<br>
Stefan<br>
<br>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8">
<title></title>
<meta name="GENERATOR" content="OpenOffice.org 3.3 (Win32)">
<meta name="CREATED" content="0;0">
<meta name="CHANGEDBY" content="Stefan Fuchs">
<meta name="CHANGED" content="20120503;23115492">
<style type="text/css">
<!--
P { color: #000000 }
-->
</style>
<p>Stefan Fuchs<br>
E-Mail: <a href="mailto:sfuchs@gmx.de">sfuchs@gmx.de</a></p>
</div>
</body>
</html>