HARDCOPY slower with more figures open?

GETFRAME is slow. I'm using the HARDCOPY function as a faster alternative (it's still way too slow) in order to capture figures (with the added benefit that I don't have to worry about accidentally capturing other windows or require the Matlab or the captured window be topmost on my screen):

http://www.mathworks.com/support/solutions/en/data/1-3NMHJ5/

However, I've come across an issue that I've not seen noted anywhere related to HARDCOPY's performance when more than one figure is open. The more figures that are open the slower HARDCOPY gets. Additionally, it seems to matter which figure I capture. The slowdown can be even more severe if I capture the figure that was created first, v.s. the one that was created most recently. Here's some code to illustrate this:

close all
clear h x
h(1) = figure;
surf(peaks(100));
set(h(1),'PaperPositionMode','auto','Renderer','opengl');
x = hardcopy(h,'-dopengl','-r0');
tic
for i = 1:200
    x = hardcopy(h,'-dopengl','-r0');
end
toc

close all
clear h x
h = zeros(1,20);
for i = 1:20
    h(i) = figure;
    surf(peaks(100));
end
set(h(20),'PaperPositionMode','auto','Renderer','opengl');
x = hardcopy(h(20),'-dopengl','-r0');
tic
for i = 1:200
    x = hardcopy(h(20),'-dopengl','-r0');
end
toc

close all
clear h x
h = zeros(1,20);
for i = 1:20
    h(i) = figure;
    surf(peaks(100));
end
set(h(1),'PaperPositionMode','auto','Renderer','opengl');
x = hardcopy(h(1),'-dopengl','-r0');
tic
for i = 1:200
    x = hardcopy(h(1),'-dopengl','-r0');
end
toc

close all

On my MacBook Pro running Mac OS X 10.6.8 and Matlab R2012a, the above returns:

Elapsed time is 3.472382 seconds.
Elapsed time is 5.997113 seconds.
Elapsed time is 12.877671 seconds.

So, when 20 identical figures are open, HARDCOPY is about 1.7 times slower to capture the most recently created figure and 3.7 times slower to capture the first. Interestingly, if the figure's Renderer property is set to 'zbuffer' and the '-dzbuffer' argument is used for HARDCOPY, the third time is about the same as the second. (EDIT: Actually, it seems to be a matter of figure window layering order, not creation order - if I call figure(1) to bring the first figure to the top before the HARDCOPY loop, then the third case takes about as long as the second. I don't know why this only happens with 'opengl' and not 'zbuffer'.) It doesn't seem to matter if DRAWNOW is called between calls to HARDCOPY or not. Similar loops with GETFRAME are slower, but do not show a slowdown when many figures are open.

Have others seen this? Is this just an artifact of how HARDCOPY works under the hood or a possible bug? Other than closing figures, are there any workarounds? Has anyone found a faster way to capture figures/axes? Thanks.

Answer 1

[Jan]

On one hand I'd avoid clear all when time is measured. It removes all functions from the memory and reloading is very time-consuming.

On the other hand hardcopy with the OpenGL renderer gets the pixel values from the OpenGL driver. If a picture is covered by a lot of other figures, it is reasonable that this takes more time.

[Andrew Horchler]

Thanks Jan. I guess that would explain the difference between the 'opengl' and 'zbuffer' cases when there are multiple windows. The OpenGL driver would have to check if any of the layered windows' content are composited (in fact, in Mac OS X the drop shadows around the figure windows do get composited). My only guess for the reason why the second loop (20 figures, capturing top one) in my examples is so much slower the first (just one figure) is that HARDCOPY just hasn't been optimized for this usage case. Maybe it's allocating the memory to copy all of the figures, doing the copy, and then throwing away all but the one figure.

Also, I'm not sure if you noticed, but I don't "clear all" for these examples (maybe you saw the "close all"?). I just clear x and h and then I warm-up of HARDCOPY before starting the timing. The timing is consistent.

[Jan]

@Andrew: You are right, no "clear all" in the code. I've read to much questions obviously.