In octave 5.1.0 the window maximize/restore button updates the axes size, however the position of uicontrols are still not updated. Tested with the demo_uicontrol.m from the wiki.

I backed out cset b57b7f3f5e61 which solves this bug and does not trigger the issue it was supposed to solve. Marking "Ready for test".

I tried to backout the changeset that prevents the figure from being correctly redrawn after resizing (http://hg.savannah.gnu.org/hgweb/octave/rev/b57b7f3f5e61?revcount=120) and

• indeed it solves this bug for me
• I can't reproduce the segfault it was supposed to resolve (see bug #44330). I tried the following

h = figure (); close (h);h = figure (); close (h);  h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h); h = figure (); close (h);

Any objection against this backout?

I'm running Nvidia driver on Cinnamon 2.8.1 (and various combinations of Cinnamon utilities in the vicinity of 2.8.1).

Here's the interesting thing.  I do

>> graphics_toolkit ('qt')
>> figure
>> sombrero

Half the time I end up with a grey screen with a white box in the upper left corner and the pager is stuck.  I've reported that bug elsewhere.  However, if the figure window appears with a proper display the sombrero appears.

Now, here's something new and interesting (pre-patch).  The first time that I grab the lower right corner and drag, the figure replots normally.  No black screen flashing, and the surface looks complete.  However, if I release the mouse and let go of the window corner then repeat this process, now the black background appears and I can see that the surface doesn't fully draw.  Instead it randomly draws somewhere in the vicinity of half the surface before doing another redraw.

Apparently there is some type of state variable inherent in this redraw (Octave or Qt) that maybe isn't being set to a proper value upon releasing the mouse.  It is probably something to do with blocking the redraw until the previous redraw is complete...  Wait!  Here's another little detail.  I was curious if maybe the problem is that I let go of the window corner in the middle of a redraw.  That appear to be the source of the problem.  If I drag the corner around, stop and wait until I'm certain the sombrero redraw is complete, then let go of the mouse button there appears to be no black screen when I repeat this little test.

Some state variable is being reset on account of a button release (or possibly more types of) events when the renderer is drawing when maybe those events should be blocked or discarded when the renderer is active.  I think it is a good guess that this is also the source of my randomly grey screen when running a simple "figure()".

Anyway, I'd say your patch is fine, but really this Qt plotting should be made robust as a main priority.  Folks have tried solving these kinds of bugs with things like fraction-of-a-second delays and so on.  That's just sweeping the dust under a rug.

I've switched over to Qt5 now.

I used Meld to look more closely at the changes.  I didn't follow through the code to see what

fp.set_boundingbox (bb, true, false);

does, but generally speaking the patch does seem to add a piece that seems missing, i.e., reaction to the Resize event.  Makes sense to me.

I was just pointing out that the now-sluggish multiple drawing with each plot might be covering up the behavior I was originally seeing with this bug report, so I can't confirm the patch does anything.  No objections to applying the patch though.

Maybe someone committed a changeset to address this issue but in a clumsy fashion.  Rik, should we locate where this plot double-draw was introduced sooner rather than later?

I've applied this patch and will note behavior before and after. 

The problem is that Qt plotting now (before applying patch) seems to have some redundancy that was introduced along the way recently.  Someone probably solved an issue which consequently draws more than once for each plot.  So, that may have solved the issue here (or at least the way I described it), or more like maybe covered up the original issue.

After applying patch https://savannah.gnu.org/bugs/download.php?file_id=38259 the only thing that stands out is that the background is more likely to turn from white to black while dragging a corner of the window to resize the plot.  It is especially likely if the window corner is dragged slowly.  Attached is a screen shot.

Without the patch I do see the black background once in a while, but it occurs at a much slower rate.

I'd say that from my perspective, given the state of Qt plotting, it might be best to lower the priority on this one.  If it solves something on Windows, go ahead and apply the patch.

OK I think I have a fix for this completely now.

Basically, before the Figure's Container gets the QEvent::Resize we resize the main window. I have then removed the unnecessary two other resizes from the after event filter.


Further in updateBoundingBox the use of gh_manager::post_function updateBoundingBoxHelper meant that the updates to the figure's main window size were occuring after other elements were informed so I have now made this updated.

What are the possible problems with this approach?

• I think we need to ensure that the ResizeFcns are not adversely affected by this. The immediate post_set could lead to slow updates when resizing figures. I have not completely tested this yet.

(file #38259)

Hi! I've just noticed this bug too.

The main issue is that the QEvent::Resize / QResizeEvents are not emitted by qt for window restore - rather you need to listen for a QEvent::WindowStateChange / QWindowStateChangeEvent, then look at the difference between the QWindowStateChangeEvent.oldState() and  QWidget.windowState().

This could probably be done in Figure.cc and then a fake QEvent::Resize could be emitted to pass the event down to all the children.

On the other issue of fast-dragging updates (first mentioned in comment #2) I agree with Dan Sebald's comment #10. I suspect that the problem is one of simultaneous read/write of window size and/or reordering of events between the octave and QT threads. Regarding failure to resize in busy octave threads - this can be a problem in matlab too.

No thanks.

I didn't look that closely at the code, but I looked close enough to get a feel for things.  I've seen these sorts of window size and update issues a lot with gnuplot development, for example, where there is the core routine and an outboard driver through a pipe.  It can get sort of tangled, adding variables here, conditional there.  Things like static methods or whatnot often seem to complicate matters rather than add benefit.

I tend to take a broader view regarding the overall communication and flow across threads.  As I see it, somewhere in the mix needs to be a Mutex to prevent a clash of simultaneous data modification and/or redraw timing.  A C callback on its own simply doesn't have that.

Personally, for elegance I would have attempted to derived Figure from, what is it, QCanvas, QGraphicsScene?  Some Qt object that already has the window modification and redraw signals as part of it.  There probably already is a signal in those types of Qt objects emitted when the window is resized.  The responding slot would either send a command to Octave core with the new size (the command interface, by construction, has a Mutex), or the window size would be copied to some shared memory with Octave core, which should have a Mutex.

There's also the question of Octave core rendering while it is processing.  It's not that important to me, but I'm sure there will be users saying "can't change the figure size while a long processing job is running".  (In fact, I think there is a related bug I've just noticed in attempting to resize when octave is processing.  Changing the window size results in the figure not being redrawn at all once the interpreter finishes processing.)  It might make sense to have Octave gl-renderer be an independent hunk of code so that resizing can be done when Octave is processing.  Also, not the easiest thing.

As I say, it's just a gut feeling that the sort of pieces to make plotting work smoothly aren't there.  Probably have to settle for with some quirky operation for the time being.

Ah, this is another of the callback sort of constructs.  That crashes because the GUI can delete the figure object asynchronously and the callback uses the pointer in a way it shouldn't.

Getting the bounding box change back to Octave figure properties is one of those things that could be accomplished with sending the core a "set()" command, if such a thing existed.  Or something similar that uses a Mutex.

Not sure this issue can be fixed too easily.

Probably a long shot, but any chance this has been affected by this change:

http://hg.savannah.gnu.org/hgweb/octave/rev/b57b7f3f5e61?revcount=120

Confirmed on a Linux machine so this is not specific to an OS.

Sample steps to reproduce:

graphics_toolkit qt
sombrero
# Click on Maximize button of figure window
# Figure will expand to fill screen, and contents will be autoscaled.

# Click on Restore (Maximize again) button of figure window
# Figure will shrink to original size, contents will be cut off

# Click in Canvas to cause update of contents

I observe the same thing on Linux when you maximize/restore a window or when dragging back a window from the screen edge (snap sizing). It also happen if you resize quickly a window using the window borders (especially when reducing its size).

If you resize a figure window via its borders the content (like plots, ...) also will be resized and repainted accordingly to the available space. But this does not work if you maximize/restore the window or double click the windows borders (this will resize the window in a way such that it uses the whole vertical or horizontal space of your screen, I don't know if this feature is also available on Linux desktops).

Any event inside the figure window will trigger a resizing/repaintng of the plots but it would be better if the figure immediatley resizes/repaints its content after maximizing/restoring the window.

Only tested on Windows 7.