5
$\begingroup$

I moved the second issue to a separate topic: 162013

Please run the code sample

enter image description here

As you can see there is a delay between the moment the calculation is finished and when the graphics is shown. And during this delay the FrontEnd is frozen, even progress indicator does not work.

It will be worse for more complicated / bigger examples. Sometimes you can predict this and e.g. rasterize / but sometimes not.

The bottom line is: users are confused.

Question

Is there a better way to deal with this delay other than putting big "rendering" message on top just before the calculation is finished?


The Pause[] in the code below is only to let ProgressIndicator spin a little longer, for illustration.

Code sample

DynamicModule[{processing1 = False, processing2 = False},
 
 data = panel1 = {};
 n = 5 10^4;
 update1[] := panel1 = Graphics[Line@data, Frame -> True];
 
 Grid[{{
    Button["run me",
     
     processing1 = True;
     data = RandomReal[1, {n, 2}];
     Pause[1];
     update1[];
     processing1 = False;
     
     ,
     Method -> "Queued",
     ImageSize -> 100 {1, 1}
     ]
    ,
    Dynamic[
     If[processing1, 
      Dynamic@ProgressIndicator[Appearance -> "Indeterminate"],
      panel1],
     , TrackedSymbols :> {processing1}]
    
    
    
    }}, BaseStyle -> CacheGraphics -> False]
 ]
$\endgroup$
7
  • $\begingroup$ I don't have time to respond thoughtfully to this. But briefly...if the delay is in the front end and cannot be moved out of the front end, then it's hopeless. The two typical examples where the delay really can't be moved out of the front end are slow visual rendering (i.e., that the FE is literally being slowed down by calls to the drawing system), or long MathLink transmission times. In your case, you're being slowed down by the former...this is empirically observable by seeing how sluggish the graphic is when resizing. $\endgroup$
    – John Fultz
    Dec 15, 2017 at 10:02
  • $\begingroup$ One could imagine, running a service front end to do the rendering and turn the result into a bitmap, which could then be communicated back to the master front end quite efficiently. This can be done fairly simply with the parallel evaluation commands. I leave that an exercise to the reader. Ultimately, this is just off-loading the rendering to another process, which is the same qualification I gave in my comment above. $\endgroup$
    – John Fultz
    Dec 15, 2017 at 10:05
  • $\begingroup$ @JohnFultz This problem arises in real-world UI's for customers. And it would be so sad to give up with CDF, or the standard FrontEnd to do this kind of smooth predictable UI's which is needed. Will there be a better FrontEnd or should we all move to the cloud and JavaScript? $\endgroup$ Dec 15, 2017 at 10:06
  • $\begingroup$ Re FinishDynamic[], to be perfectly honest, I'm not going to claim to completely understand how it behaves. It has, on occasion, defied my expectations as well, and I've never run it to ground. $\endgroup$
    – John Fultz
    Dec 15, 2017 at 10:07
  • $\begingroup$ @JohnFultz yes, that will do if you have a static output, and I will try to prepare this workaround as an answer. It gets complicated when you have EventHandlers etc inside. $\endgroup$
    – Kuba
    Dec 15, 2017 at 10:07

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.