Re: Win7 "not responding"; WinXP no problem w/ my Manipulate
- To: mathgroup at smc.vnet.net
- Subject: [mg129811] Re: Win7 "not responding"; WinXP no problem w/ my Manipulate
- From: John Fultz <jfultz at wolfram.com>
- Date: Fri, 15 Feb 2013 03:35:33 -0500 (EST)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Delivered-to: l-mathgroup@wolfram.com
- Delivered-to: mathgroup-newout@smc.vnet.net
- Delivered-to: mathgroup-newsend@smc.vnet.net
- References: <jf6908$gb3$1@smc.vnet.net> <20130214070938.C49AD6924@smc.vnet.net>
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 time-consuming 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 at wolfram.com User Interface Group Wolfram Research, Inc. On Feb 14, 2013, at 1:09 AM, Frank Iannarilli <frankeye at 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/de-ghosting-your-windows.aspx > > does describe the underlying cause of why Win7 is less forgiving then WinXP of Manipulate and Dynamic cells whose evaluation-loop computations run too long when in (default) SynchronousUpdating->True mode (i.e. clogging the preemptive front-end/kernel link, thus blocking the front-end and triggering Win7's treatment of unresponsive programs). > > So here are my findings/solutions for accommodating long-running (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 front-end susceptible to Windows Ghosting. > > > * If a Button included as a Manipulate control invokes long-running 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 lock-up the front-end. (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. > >
- References:
- Re: Win7 "not responding"; WinXP no problem w/ my Manipulate
- From: Frank Iannarilli <frankeye@cox.net>
- Re: Win7 "not responding"; WinXP no problem w/ my Manipulate