3

Consider the following Manipulate:

Manipulate[Plot3D[Sin[x] Cos[y], {x, 1, 5 a}, {y, 1, 5 a}], {a, 1, 5}]

When trying to step forward clicking the line of the slider, the plot will render fairly quickly. However using the animation control: + button or – button, the rendering process takes several seconds, sometimes up to eight seconds.

As seen below, the 3D-plot is not rendered approx. 3 seconds after pressing the + button.

enter image description here

Below, the slider has been pressed followed by an almost instant rendering.

enter image description here

This may seem like an insignificant phenomenon but the reason for this difference in speed isn't clear to me.

Any suggestions as to why this is and how the delay can be avoided?

MathLind
  • 1,697
  • 1
  • 13
  • 22

3 Answers3

4

It is as if the Animator is waiting 3 sec. to see if you are going to make further clicks, before triggering the final ($ControlActiveSetting == False) update. Indeed, one can see that there is a delay after hitting the plus button (or minus button), before ControlActiveSetting is changed from True to False; almost immediately after the setting changes, the plot is updated.

Manipulate[{Dynamic[$ControlActiveSetting], 
  Plot3D[Sin[x] Cos[y], {x, 1, 5 a}, {y, 1, 5 a}]}, {a, 1, 5}]

This can be confirmed with LinkSnooper as well. I could find no $FrontEnd options or SystemOptions that might control this delay.

My guess is that the delay allows the user to adjust several controls before a high-quality update is triggered. Since these might take a long time, I assume Wolfram thought that a three-second (or whatever) delay is an appropriate compromise.

Update: Addendum

I probably should have pointed out, especially since it is not often mentioned, that by default, plots depend on $ControlActiveSetting because the default option setting PerformanceGoal -> $PerformanceGoal has the value

OwnValues[$PerformanceGoal]
(*
  {HoldPattern[$PerformanceGoal] :> 
    If[$ControlActiveSetting, "Speed", "Quality"]}
*)

Anyone using Manipulate with plots will be familiar with the effect. This and the system setting $ControlActiveSetting to True when a control is operated are the causes.

Michael E2
  • 235,386
  • 17
  • 334
  • 747
3

In light of Michael's revelation the only solution I can think of is to make the early rendering higher quality as described in PolarPlot render oddities. If the higher quality version renders faster than the delay to $ControlActiveSetting this will result in faster updating.

Manipulate[
 Plot3D[Sin[x] Cos[y], {x, 1, 5 a}, {y, 1, 5 a}, 
   PerformanceGoal -> "Quality"],
 {a, 1, 5}
]
Community
  • 1
Mr.Wizard
  • 271,378
  • 34
  • 587
  • 1,371
  • 1
    @MathLind This is a good answer, which I upvoted, and while it alludes to a partial reason given in the linked question, it primarily gives a workaround. But the Question asks "Why?", not "How?" You could consider changing your question to clarify the relationship between Q and accepted A. (Since your example came straight from the docs, I thought you were genuinely interested only in the Why question, which I also found much more interesting than how to avoid it, even if my findings ran into a wall that probably only WRI can see behind. The How question has been asked before in several ways.) – Michael E2 Feb 01 '15 at 14:08
  • @MichaelE2 Thank you for clarification which makes a lot of sense. Honestly in my head, I intended to ask both Why and How. I will edit my question accordingly. BTW, what is the meaning of "straight from the docs" ? – MathLind Feb 01 '15 at 14:14
  • @MathLind I may be misremembering...I thought the plot of Sin[x] Cos[y] is an example actually in the documentation. – Michael E2 Feb 01 '15 at 14:17
  • @MichaelE2, I don´t know. I will have to check it. Thanks anyway. – MathLind Feb 01 '15 at 14:18
  • @MathLind As always what you do with the Accept is entirely your prerogative, but I would support your switching the Accept to Michael's answer. I really intended mine to complement his, not supplant it. – Mr.Wizard Feb 01 '15 at 14:21
  • @Mr.Wizard, Quite fair in the light of the above. Thanks. – MathLind Feb 01 '15 at 14:22
  • @MathLind Don't worry about it. There's something like it, but it's not exactly the same. I just hastily concluded yesterday that you used it as an example for your question, which would have been fine, btw. A simplified example is usually appreciated. (Let's delete some of these comments before Mr.Wizard wakes up. :) – Michael E2 Feb 01 '15 at 14:22
  • @MichaelE2 lol ;-p – Mr.Wizard Feb 01 '15 at 14:22
2

In Version 9, the option settings ContinuousAction->True for Manipulate combined with PerformanceGoal -> "Quality" for Plot seems to eliminate the delay.

Using @Michael E2's example:

Manipulate[{Dynamic@$ControlActiveSetting, 
  Plot3D[Sin[x] Cos[y], {x, 1, 5 a}, {y, 1, 5 a}, PerformanceGoal -> "Quality"]}, 
  {a, 1, 5}, ContinuousAction -> True]

enter image description here

kglr
  • 394,356
  • 18
  • 477
  • 896
  • It works the same in V10, too. However, I don't see any difference in behavior of either $ControlActiveSetting or the plot if I omit ContinuousAction -> True (Mr. Wizard's solution). It seems to me the principal change is that the plot no longer depends on $ControlActiveSetting because of the setting of PerformanceGoal. – Michael E2 Feb 01 '15 at 12:53