Services & ResourcesWolfram ForumsMathGroup Archive

[Date Index] [Thread Index] [Author Index]

Re: Win7 "not responding"; WinXP no problem w/ my Manipulate

• To: mathgroup at smc.vnet.net
• Subject: [mg129793] Re: Win7 "not responding"; WinXP no problem w/ my Manipulate
• From: Frank Iannarilli <frankeye at cox.net>
• Date: Thu, 14 Feb 2013 02:09:38 -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>

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.  

• Follow-Ups:
  • Re: Win7 "not responding"; WinXP no problem w/ my Manipulate
    • From: John Fultz <jfultz@wolfram.com>