I've got a little widget that animates a sequence of images by calling the "image()" function repeatedly with new images in a sequence. Normally the animation proceeds reasonably fast around 50-60 frames per second. However, if the mouse is in the figure window and moves around (not even clicking on anything), then the animation slows to a crawl (about 2-3 frames per second) as long as the mouse moves in the figure window. (See code at bottom for simple example to replicate this).
I've checked to ensure that the 'WindowButtonMotionFcn' figure callback is disabled (as are all other figure callbacks). I can't find any other figure, axes or even image objects that might be triggered by mouse motion in the figure window.
If I run the profiler and compare results with and without the mouse moving around the figure window, I see the function:
(and its dependent functions ) is getting called thousands of times and is consuming 90% of the runtime when the mouse is moving around I tried turning off both the figure's toolbar and the figure's menu bar, e.g:
hFigure.ToolBar = 'none';
hFigure.MenuBar = 'none';
and that slightly alleviates the issue somewhat, but not much (perhaps 10-20% better) . Further, even with the toolbars turned off, the profiler still indicates that
is still consuming 90% of the run time whenever the mouse is moving around. There also is the function
that is also getting called thousands of times and is consuming some of the time. So I also disable the AxesToolbar by:
axesTB = get(hAxes,'ToolBar');
axesTB.visible = 'off';
axesTB.BusyAction = 'cancel';
(Unlike the figure toolbar, there doesn't seem a setting to completely disable a AxesToolbar). Anyway, turning off the axesTB didn't seem to help.
% This code can be used to illustrate the issue of slowly updating graphics.
%Clearing the axes with "cla" before the image() call doesn't change the result. However, this version of the code is seemingly NOT impacted by this issue or very little:
hImg = image(rand(300,300),'CDataMapping','scaled');
hImg.CData = rand(300,300);
In the latter case, the profiler say that the function
still gets called a whole bunch of times but it ends up only consuming about 15% of the runtime (not 90+%), and the animation proceeds at 50+ FPS. So there is something about the combination of a moving mouse and creating new objects (rather than changing attributes of existing objects) that seems to grind matlab graphics to a halt. While I clearly point out a workaround for my little example above, in the general case, such workarounds are not always possible. It seems odd that moving a mouse while drawing objects in a figure shouldn't necessarily slow down things as much as it appears to do.