Wed 24 Aug 2016 01:52:39 PM UTC, comment #12:
Interestingly enough, I've noticed that plots now run faster (such as when runing dump_plot_demos). It seems that having the default figure size differ by 1 pixel from the created size was triggering a whole bunch of callbacks/listeners that slowed things down.
|
Wed 24 Aug 2016 05:36:38 AM UTC, comment #11:
Works here, and the CPU meter is near zero so no sort of redraw going on. Thanks.
|
Wed 24 Aug 2016 02:16:23 AM UTC, comment #10:
works for me.
Dmitri.
--
|
Wed 24 Aug 2016 12:32:39 AM UTC, comment #9:
I pushed a patch for bug #48522.
I can't confirm that it is related, but if someone can test with a cset >= 22370 that would be great.
|
Thu 18 Aug 2016 08:42:09 AM UTC, comment #8:
Note for later: this may be related to bug #48522
|
Thu 18 Aug 2016 08:08:41 AM UTC, comment #7:
Hi,
I won't be able to look at this until a few days ago.
Anyway as you can see in the excerpt in comment #6, this listener is probably not the one to blame as it doesn't actually change the figure position. AFAIR its purpose (and a few other lines) is be able to keep track of the figure size and adjust the position of annotation objects that have absolute units. In fact Matlab has a figure callback property called "sizechangedfcn" which would be very handy here.
|
Mon 15 Aug 2016 03:18:21 AM UTC, comment #6:
Nice work. So the annotation code looks to be it. Have a look at this code:
The above routine is installed as a "listener". A "listener" is a callback whenever the indicated property changes:
So, the routine gets called whenever the 'position' property for the axes changes. But it looks as though what is inside of update_figsize_points() could affect the axes size, e.g., set (hax, "figsize_points", pos(3:4)); That's a feedback loop.
Notice that there is a block
attempting to stop this type of feedback or maybe to prevent another disruptive call when the user is dragging the window. [This is starting to sound familiar...seems this kind of thing came up once before.] I'm going to send an email to the author at the top of annotation.m.
|
Mon 15 Aug 2016 03:04:22 AM UTC, comment #5:
Simplified even further:
+varbatim+
annotation ("textbox", [0.1 0.9 0.9 0.1], "String", "A");
-verbatim-
Actually space on top of the text also grows (perhaps proportionally).
Dmitri.
|
Mon 15 Aug 2016 02:55:34 AM UTC, comment #4:
For me the bug is triggered by annotation. I.e.
the following code:
will draw an empti plot with a text on top and if I try to drag
the window the empty space keeps on growing down.
Dmitri.
|
Mon 15 Aug 2016 02:41:12 AM UTC, comment #3:
OK, good to know. I too have Gnome 3 on this system. So, something particular about Qt5 behavior is happening--something along the lines that the window size is being adjusted depending upon what is drawn inside. Now, we should investigate what code is actually controlling that. Could be desktop code, could be Octave code.
In any case, it could still be that the Octave plotting/rendering code is ultimately responsible for this. I think I see what is happening. Well, I should say that I managed to make the expansion stop by moving the window. And when it stopped, the location text in the footer was only half visible. Somehow that is plotting area plus the footer is expanding, or maybe the footer gets adjusted and then the Qt window is expanding along with it (maybe there is a Qt window mode setting to control that behavior, i.e., expand the window to match contents, or keep window size static). We should look for such a setting, and maybe that will be the simple solution to this.
What's causing this looks to be a feedback type of sequence. This is only happening with the four subplot case. Activate rotation, and rotate one of the subplot, say the bottom right. Watch how that affects the top two plots. They get redrawn, probably because of the dynamic sizing of the space used by the bottom right rotated figure. (This is especially noticeable when rotating one of the spheres in the first two demos. The plot changes scale dramatically and the location of the title will even change sometimes. At first I thought this behavior interesting, but after time I've come to not like it at all. Anyway...) It's that dynamic adjustment of space that is probably driving the remaining subplots to be redrawn with a pixel or two size difference. That, in turn, causes the window to adjust and redraw...but now with the new dimensions it is some other subplot that changes size a little bit. This just keeps going on that way. So, maybe if we get rid of that changing scale with rotation/view behavior, this feedback will go away.
|
Mon 15 Aug 2016 12:07:19 AM UTC, comment #2:
That must be some interaction with desktop environment. I just
tried to run in "Plasma" (kde/qt) desktop and everything looked fine.
(In Fedora default desktop is Gnome (gtk))
Dmitri.
|
Sun 14 Aug 2016 02:54:51 PM UTC, comment #1:
If I grab the 3rd window (the last one, with 4 plots) and move it slightly it starts to grow vertically until I release the mouse.
I do not see any other problems (tried it on two different computers).
Qt5-5.6.1
Dmitri.
|
Sun 14 Aug 2016 07:03:08 AM UTC, original submission:
Using Qt5, the Qt graphics toolkit exhibits more, or makes more likely, problems when plotting.
From a fresh launch, when I run in the GUI
about 20% of the time I get a grey window, an example of which is attached.
Also, the pager seems stuck every time no matter if the plot window looks correct. Although the output to the terminal window stops, typing <return> will bring the next demo, etc. After the demo, I can type "exit" and the GUI shuts down appropriately.
Another observation is that the third demo in isosurface with the four subplots continues to replot expanding by about five pixels each time. After twenty seconds the plot window has expanded past the screen. The only way to stop the re-plotting is to close the figure window.
From a fresh launch, when I run in the GUI
the pager does not get stuck and I haven't seen the first demo plot be grey yet. However, the third demo still does the replotting and expansion.
|