bugGNU Octave - Bugs: bug #54083, Qt toolkit figures don't always...


bug #54083: Qt toolkit figures don't always redraw on resize until releasing the mouse button

Submitter:  Dan Sebald <sebald>
Submitted:  Thu 07 Jun 2018 09:39:48 PM UTC
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Incorrect Result
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


Sun 03 Mar 2019 06:06:44 PM UTC, comment #5: 

@Dan: Thanks, so I'll close this report.

Pantxo Diribarne <pantxo>
Project Member
Sun 03 Mar 2019 05:58:56 PM UTC, comment #4: 

This seems to have gone away.  The black flashing window doesn't happen in Qt anymore either.  Still clunky slow, but no visually annoying flashes.

Dan Sebald <sebald>
Sun 03 Mar 2019 05:37:21 PM UTC, comment #3: 

I cannot reproduce this bug on linux. Can we close this report or is it still valid? In case someone can reprode, it would help to have a detailed sequence of plot/drag actions.

Pantxo Diribarne <pantxo>
Project Member
Fri 26 Oct 2018 09:26:53 AM UTC, comment #2: 

Just a note:
On my Windows boxes I have "lazy focus" and lazy window raising enabled. I see that automatic resizing happens instantaneously after the plot window gets focus again (i.e., after hiding behind another window and then brought to foreground by just hovering the mouse cursor over it).

So it feels like some Qt command is missing that links plot window interaction to redrawing.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 08 Jun 2018 08:11:50 AM UTC, comment #1: 

It is my experience that at least on Windows, since a long time the qt toolkit never redrawed automatically after plot window resize actions. I always use the "Autoscale" buttons to redraw after resizing. (Hmmm, maybe the latter relates to bug #54079?)
In fact I vaguely figured that this had become the official behavior.

But I just tried and found that redrawing of very simple plots like "plot (sin (1:10))" sometimes work automatically with qt after resizing the window.
It seems that simple & small resize moves (of the plot window border) work, but resizing by dragging some window border hence and forth indeed leads to no redrawing.

The fltk toolkit just seems to have a higher tolerance.
For simple plots, redrawing is instantaneous. But I often draw more complicated topographical maps (from shapefiles) with various overlays and resizing those seldomly results in an automatic redraw, with qt and fltk.

I found no difference with or without releasing mouse buttons.

BTW I never noted a "black background flash" with the qt toolkit.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 07 Jun 2018 09:39:48 PM UTC, original submission:  

First, I just want to note that it's fairly well known that Qt graphics toolkit resizing has this black background flash.  I think that has to do with a delay introduced to lessen a multi-threading bug.  However, now the FLTK graphics toolkit is exhibiting the same black-background flash that I know it never used to have.  In the FLTK case there isn't a threading issue.  So, I'm wondering if there were a fix for Qt in a way that caused the FLTK situation to arise.

The bug of the Summary is probably closely related to the above paragraph.  I've notice when resizing a Qt window (not FLTK) that the plot redraws sometimes but not always.  That is, there are some cases where I dragged the Figure window slightly bigger but the plot itself does not adjust...not until I release the mouse button--then the plot is redrawn to correctly fill the available space.  So, it seems as though the plot isn't being redrawn with every mouse event, just select events.  Could it be that some of those events are being lost because a redraw/re-render is busy?

Dan Sebald <sebald>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by sebald (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only project members can vote.





    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-03 pantxo StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2019-03-03 pantxo StatusNone Need Info

    Back to the top

    Powered by Savane 3.9