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

8 Ansichten (letzte 30 Tage)
Evan
Evan am 15 Aug. 2017
Kommentiert: Evan am 21 Aug. 2017
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.
  7 Kommentare
Jan
Jan am 21 Aug. 2017
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
Evan am 21 Aug. 2017
Bearbeitet: Evan am 21 Aug. 2017
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.

Melden Sie sich an, um zu kommentieren.

Antworten (1)

Neil Guertin
Neil Guertin am 21 Aug. 2017
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.
  1 Kommentar
Evan
Evan am 21 Aug. 2017
That was the recommendation I got from Mathworks after submitting a bug report. It does not seem to work every time, unfortunately:

Melden Sie sich an, um zu kommentieren.

Kategorien

Mehr zu Graphics Performance finden Sie in Help Center und File Exchange

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by