Search All of the Math Forum:
Views expressed in these public forums are not endorsed by
NCTM or The Math Forum.



Re: Win7 "not responding"; WinXP no problem w/ my Manipulate
Posted:
Feb 15, 2013 3:35 AM


This is a reasonable and accurate explanation of what's going on and what the preferred mechanisms of dealing with it are. These would be preferred even under older Windows OS's or other operating systems because use of Method>"Queued" or SynchronousUpdating>False for timeconsuming operations will leave the FE responsive, and having a responsive FE should be important for any interface.
I'd like to fix one other inaccuracy not yet addressed that came up in this thread. In an earlier post, you said:
> I see that Mathematica 9.0, unlike Mathematica 8 and before, evidently does not employ java to implement its Manipulate functionality.
Mathematica has *never* employed Java to implement Manipulate functionality.
John Fultz jfultz@wolfram.com User Interface Group Wolfram Research, Inc.
On Feb 14, 2013, at 1:09 AM, Frank Iannarilli <frankeye@cox.net> wrote:
> I think I finally have the correct diagnosis and solution(s), below. > > The Windows Ghosting "solution" I posted above is not a solution. However, the link: > > http://blogs.technet.com/b/askperf/archive/2010/09/10/deghostingyourwindows.aspx > > does describe the underlying cause of why Win7 is less forgiving then WinXP of Manipulate and Dynamic cells whose evaluationloop computations run too long when in (default) SynchronousUpdating>True mode (i.e. clogging the preemptive frontend/kernel link, thus blocking the frontend and triggering Win7's treatment of unresponsive programs). > > So here are my findings/solutions for accommodating longrunning (i.e. > 5 seconds) computations comprising the Manipulate or Dynamic argument, probably recommended in general but specifically geared to Win7: > > > * Use the option SynchronousUpdating>False. > > > * Don't rely on the idiom of wrapping Manipulate within Style[..., DynamicEvaluationTimeout>10000]. This would prevent the $Abort timeout, but under Win7 makes the frontend susceptible to Windows Ghosting. > > > * If a Button included as a Manipulate control invokes longrunning computation, use the Button option Method>"Queued". > > > * Be mindful with "interior" Dynamic cells, e.g. Dynamic inside Manipulate, for by default these use SynchronousUpdating>True. Heavy computation with in their arguments can lockup the frontend. (I was heedless of this point, which is why in my original post, I gained no relief merely by employing SynchronousUpdating>False in the "outer" containing Manipulate  I also needed this option in some of my interior Dynamic cells). > > > * Realize that with ContinuousAction>False (and SynchronousUpdating>False, the user can still muck with controls in a manner that generates excessive delay, which may be confusing. For example, for the cell: > > Manipulate[Pause[10]; x, {x, 0, 10}, ContinuousAction > False, > SynchronousUpdating > False] > > the user can drag the slider in all manner during the Pause, but with each release of the mouse, she generates another evaluation loop that gets cued to the main link, therefore the overall manifested pause delay can be tens of seconds, not merely the nominal Pause[10] 10 secs. > >



