Finding bugs can be a daunting task sometimes… Today I was stucked with an error that eventually turned out to be due to a very common mistake. To my defense, it was about a mechanism that is not really intuitive on a first look : drawnow.
In this post, I talk about Matlab calculation thread, Java thread and a very common problem : Why does this stupid call to graphic display is not executed in its time?
Let’s suppose you execute the following code
figure(1); for i=1:1000 T(i)=cos(i); plot(T); end
First, I know I don’t preallocate. This is intentional.
This code will provide you with a figure with a cosinus curve in the end but you won’t see the plot “filling up” in front of you.
Some might say : it’s because it is calculated too fast by the computer!
In fact, no, here I intentionaly made my code very very bad. No preallocation and a call to graphics in a for loop. Double terrible. So why don’t we see the plot being slowly filled on the screen?
This is due to some very fundamental properties of how graphics and calculations are organized in Matlab and it is VERY important to understand this point.
For the most part, Matlab runs its calculation on a single calculation thread (it is not exactly true, most matrix calculations are multithreads now but that is hidden to you). BUT I am sure you have noticed that when you run a calculation and a GUI, sometimes the GUIs are still responsive. This is because the graphics in Matlab runs on a different thread, a Java thread called the Event Dispatch Thread (EDT). What all of this means?
The EDT is capable of sort of storing all you calls to graphics in a queue as you creates them BUT the Matlab calculation thread has always the priority so Mathworks allowed the calls in the EDT to be executed at certain precise moments. These moments are creating a new figure, use getframe, when you ask for keyboard input, … and going back to the Matlab prompt at the end of your function (which is what happened in our example). A complete list of these moment is available here.
Most of the time, this will be enough as you only cares of taking a look at this graphics when the calculation is finished. So for most users, they won’t even NOTICE that all of this is happening in the background.
However, sometimes, this is not enough. You WANT this figure to be updated and the EDT to be ‘flushed’. Your calculation is very long or you need it for your interface to behave properly. This is the role of drawnow as in this new version of the code
figure(1); for i=1:1000 T(i)=cos(i); plot(T); drawnow; end
Here, drawnow forces Matlab to pause its ongoing computation thread in order to execute pending graphic updates. This is why, when running visual code, you might suddenly “see” the figure window respond or fill up after being inactive. However, it’s important to be conservative with drawnow, as it halts numerical processing which can become a bottleneck in performance-sensitive scripts.
Many developers encounter confusing scenarios where they’ve issued graphics commands but nothing seems to happen. Often, the culprit is a nearby for loop or a heavy computation that monopolizes Matlab’s attention. In those cases, drawnow serves to gently redirect control back to the graphics engine and bring your visual output to life.
If you’re exploring ways to better manage these thread interactions in real-world scripts or want to see how others solve similar display lag issues you might find helpful examples in this curated Matlab 관련 주소모음 자료 that showcases practical uses of drawnow, performance tips, and visualization workflows.
Code of “Draw me now” 1.28 KB