Best way to keep sequential graphics-updating commands from interfering?

I've noticed that sometimes, performing multiple graphics-manipulating actions in immediate succession can lead to irregularities in rendering. By "irregularities," I mean that the results look different if I insert pauses (say 1 second) between each action.

In some cases, this can lead to pretty nasty effects, like axis labels getting cut off (which is actually good because it alerts me to the problem which I can then fix), but for the most part the effects are more insidious. This is a problem for me because I'm trying to generate plots which will eventually make their way into publication-quality figures.

Is there any way to avoid this behavior short of inserting a sizeable pause before each graphics updating command? I tried hiding the figure until the end, but that didn't have any effect.

MATLAB Version: 9.1.0.441655 (R2016b)

Operating System: Linux 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64

Java Version: Java 1.7.0_60-b19 with Oracle Corporation Java HotSpot™ 64-Bit Server VM mixed mode

Edit: I've done some testing and I'm able to reproduce at least one of these glitches.

After a set of axes are created, the 'Position' value doesn't settle down to its final value right away. So if you create a set of axes and then immediately query the Position, it may not reflect what the position actually ends up being. This seems to be worse for subplot() than axes():

The above plot was generated in software OpenGL mode.

In my particular case, I was trying to make a plot a little shorter, so I was doing something like:

hAx = subplot(a,b,c);
hAxPos = hAx.Position;
hAx.Position = [hAxPos(1) hAxPos(2) hAxPos(3) 0.5*hAxPos(4)];

Because the value returned to hAxPos wasn't "right," (hAxPos(2) was smaller than the steady-state value) this produced in non-desirable results.

I've attached some code to demonstrate the behavior and interrogate the time-dependence of the axes position.

So it's nice that I have an understanding of this particular bug. But my original question still remains: is there a way to avoid this sort of thing in general? I suspect there are other "quirks" that I don't know to specifically mitigate in my code.

[Walter Roberson]

This sounds like a graphics driver problem. Which card are you using and which driver?

[Walter Roberson]

What does

opengl info

show?

[Evan]

                          Version: '3.0 Mesa 17.0.7'
                           Vendor: 'Intel Open Source Technology Center'
                         Renderer: 'Mesa DRI Intel(R) Ivybridge Mobile '
                   MaxTextureSize: 16384
                           Visual: 'Visual 0xb9, (RGBA 32 bits (8 8 8 8), Z depth 16 bits, Hardware acceleration, Double buf…'
                         Software: 'false'
             HardwareSupportLevel: 'full'
        SupportsGraphicsSmoothing: 1
    SupportsDepthPeelTransparency: 1
       SupportsAlignVertexCenters: 1
                       Extensions: {225×1 cell}
               MaxFrameBufferSize: 16384

[Walter Roberson]

As an experiment try

opengl software

and then try the plots.

I cannot tell from the output which card that is, other than it is Intel.

[Evan]

opengl software doesn't seem to make any difference. I did some testing and edited my question.

[Jan]

The code fails due to an undefined 'yLoc'. I do not observe any problems under Windows7/R2016b. Note that subplot calls axes also, so it is strange that you find a difference. Do the problems occur with the Painters renderer also?

[Evan]

Thanks for pointing that out, Jan. That was from an old version of the code and I didn't clear the leftover workspace variables before testing and posting. It should be fixed now.

The behavior doesn't change in any qualitative fashion when I use the Painters vs. opengl renderer.

Regarding your results - I have tested this on a colleague's Windows 10 system running 2016a (I think), and the problem showed up there as well.

Answer 1

[Neil Guertin]

Add a call to "drawnow" after the call to "subplot". This will force the figure to render and finish calculating the axes position. "pause" will also force a render, but you should use "drawnow" instead.

[Evan]

That was the recommendation I got from Mathworks after submitting a bug report. It does not seem to work every time, unfortunately: