Is PAUSE a superset of DRAWNOW?

Does pause also always also do an implicit drawnow? Does it ever make sense to do

drawnow
pause(1)

instead of just

pause(1)

?

Put another way, is there any difference between pause(0) and drawnow?

The pause reference page is not clear on this issue. The "tips" section says that rendering continues, but does not say that it flushes the queue.

FYI: This question was inspired by the discussion on the answer to this other question.

Answer 1

[Matt Fig]

Interesting. In the DRAWNOW doc for 2007b, PAUSE is listed in the bulleted list of events that flush the event queue. But the current doc eliminates this bullet.

In general, even if PAUSE does flush, PAUSE is not a super-set of DRAWNOW because you have much more control over the event queue with DRAWNOW. For example:

drawnow discard
drawnow expose
drawnow update

So they may have some overlapping utility, but they do serve different purposes.

Answer 2

[Bill York]

Pause is not a superset of drawnow under all conditions.

In general, pause will "pause" longer than drawnow and is effectively a superset.

In some situations though, pause may not wait long enough.

For example, pause(.001) may wait for less time than drawnow.

So if you want to slow down a loop by pausing for 1 second, it will have the same effect as calling drawnow then pause.

But if you want to slow down a loop by some very small amount of time, you may need a drawnow first to be sure incoming events get flushed.

Answer 3

[Jan]

Documentation of Matlab 2009a:

"DRAWNOW is called implicitely ... when executing ... pause".

I had problems creating a movie using GETFRAME, if the window contains UICONTROLS: The corresponding rectangles arenot drawn such that I can see the window below the Matlab figure in Matlab 2009a. PAUSE(0.02) before GETFRAME solves the problem, while DRAWNOW does not.

Answer 4

[Yair Altman]

For the reasons that Bill mentioned above, in my work which often involves Java GUI that requires explicit flushing and waiting for the EDT to complete processing, I generally use both pause and drawnow - I discovered via trial-and-error that I need both in order to ensure proper rendering. So the following line appears very often in my code (quite possibly even in places where it's not strictly needed):

   drawnow; pause(0.05);

The actual needed value of the pause may vary, depending on GUI complexity and CPU power/load, but 0.05 seems to be large enough for most cases, while being small enough to be virtually unnoticeable by the user. In rare cases I needed to go as high as 0.1.

[Daniel Shub]

I there a reason you don't create a new function for this? Potentially a new release will need a longer/shorter time to flush and if you use a function you will only need to change one line. Then again, changing one line will affect a lot of code and therefore require huge amounts of testing. Did you try a function and experience problems or rule it out for a reason?

[Yair Altman]

Daniel - the reason is that different applications, workflows and GUI components require different pause duration. So even on a single Matlab release and in a single application, I might need to use different pause values.

Answer 5

[Eduard]

I just stumbled across this topic and in my application it's obvious that pause does not include an implicit drawnow (or at least has a slightly different behavior).

In R2015a I have a GUIDE GUI in which a loop constantly updates data in a GUI graph but uses either pause or drawnow to yield execution and allow GUI events to be processed.

Turns out that pause does not do everything drawnow does. In my experiments some scheduled events were only processed after multiple iterations of the update loop when using pause(eps) (which I assumed to be the shortest possible pause duration) whereas they were consistently processed when using drawnow. On the other hand execution of the loop was much faster with pause(eps).

Edit: I suspect pause yields execution to GUI events for as long as the pause duration allows and continues to execute the paused thread as soon as the intended pause duration is reached or exceeded. This is also consistent with the observation that pause(0) seems not to yield execution at all, probably because the thread pauses but is immediately resumed by the scheduler because the zero pause duration is by definition already exceeded.