GUI occasionally fails to respond to window resize

[Tristan Croll]

Probably another Linux-specific PyQt bug? On my Linux machine, occasionally ChimeraX will enter a state where the various GUI widgets stop responding to resizing of the main window - that is, the window itself will expand, but the OpenGL window, Log, Models panel etc. will stay at a fixed size. I'm afraid I haven't been able to pin down the event that triggers it (and there's no error message), but once it enters that state it seems to last for the remainder of the session.

[Tom Goddard]

I have observed this and I think Elaine has too on macOS.

It is likely a Qt bug but we do not know how to reproduce it. Definitely tell us if you figure out the magic steps to make it happen. Possibly we could find a Qt bug report that describes this problem.

[Tom Goddard]

I observed this during a demo today. I opened a session file containing some light microscopy. Then tried "windowsize 512 512" and it resized the main ChimeraX window but none of the panels resized and the main graphics did not resize. This made the window smaller so the command-line was no longer visible. Resizing the window manually showed that none of the panels were resizing. I believe I had restarted ChimeraX then opened the session (demonstrating session save / restore). I just tried reproducing this, thinking the session restore is what caused it -- it did not reproduce. At the time I was mirroring to a projector with low resolution set to 720p in macOS 10.13 preferences. Maybe that is related. I just tried with the display at lower resolution so the initial ChimeraX window does not fit. Did not exhibit the bug.

[Tom Goddard]

I did not see any Qt bug report describing this resize bug. Also tried 10 times to reproduce it with the session that produced it earlier today and it never reproduced.

[Tristan Croll]

This may be related to #949. At least, I can replicate the behaviour in Linux as follows:

• Create a floating widget, start dragging it around and then quickly move the mouse so the widget drops focus as described in #949.
• Resize the main window. All its panels will fail to resize.
• Move the mouse back over the title bar of the floating widget to regain focus, and properly drop it this time.
• Resize the main window. Everything is well-behaved again.

Obviously not exactly the same behaviour, since #949 doesn't seem to affect the Mac. But I also spent some time playing around with the below, and moving widgets around while the handler is active causes all sorts of window-size weirdness (dragging around a floating panel causes the main window to get progressively smaller and smaller with each iteration).

class Resize_Tester:

def init(self, session):

self._counter = 0
self._grow_on = 0
self._shrink_on = 25
self._loop_size = 50
self.session = session

def grow_shrink_loop(self, *_):

from chimerax.core.commands import windowsize
self._counter = (self._counter+1) % self._loop_size
c = self._counter
if c == self._grow_on:

windowsize.window_size(self.session, 1296, 886)

elif c == self._shrink_on:

windowsize.window_size(self.session, 512, 512)

rt = Resize_Tester(session)
h = session.triggers.add_handler('new frame', rt.grow_shrink_loop)

[Tristan Croll]

Incidentally, using the 'graphics update' trigger instead causes a crash in the graphics system if an ISOLDE simulation is running. Probably not worth chasing up, but traceback is below in case it's important.

Traceback (most recent call last):
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/updateloop.py", line 61, in draw_new_frame
view.draw(check_for_changes = False)
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/graphics/view.py", line 195, in draw
draw_opaque(r, mdraw)
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/graphics/drawing.py", line 1309, in draw_opaque
_draw_multiple(drawings, renderer, identity(), Drawing.OPAQUE_DRAW_PASS)
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/graphics/drawing.py", line 1324, in _draw_multiple
d.draw(renderer, place, draw_pass, selected_only)
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/graphics/drawing.py", line 618, in draw
self._draw_children(renderer, pp, draw_pass, selected_only)
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/graphics/drawing.py", line 649, in _draw_children
d.draw(renderer, place, draw_pass, selected_only)
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/graphics/drawing.py", line 618, in draw
self._draw_children(renderer, pp, draw_pass, selected_only)
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/graphics/drawing.py", line 649, in _draw_children
d.draw(renderer, place, draw_pass, selected_only)
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/graphics/drawing.py", line 618, in draw
self._draw_children(renderer, pp, draw_pass, selected_only)
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/graphics/drawing.py", line 649, in _draw_children
d.draw(renderer, place, draw_pass, selected_only)
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/graphics/drawing.py", line 613, in draw
self.draw_self(renderer, place, draw_pass, selected_only)
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/graphics/drawing.py", line 637, in draw_self
self._draw_geometry(renderer, selected_only, opaque_only = any_transp)
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/graphics/drawing.py", line 667, in _draw_geometry
ds.activate_bindings()
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/graphics/drawing.py", line 1653, in activate_bindings
bi.activate()
File "/home/tic20/apps/chimerax/lib/python3.6/site-packages/chimerax/core/graphics/opengl.py", line 1471, in activate
GL.glBindVertexArray(self._vao_id)
File "errorchecker.pyx", line 53, in OpenGL_accelerate.errorchecker._ErrorChecker.glCheckError (src/errorchecker.c:1218)
OpenGL.error.GLError: GLError(
err = 1282,
description = b'invalid operation',
baseOperation = glBindVertexArray,
cArguments = (2,)
)

[Tristan Croll]

Confirmed as a Qt bug, I think. After installing Qt 5.9.3, run qtcreator and open the dockwidgets example. Build and run it, tear away one of the docked widgets with the mouse, drop it, then picking it up and dragging it again reproduces #949. Resizing the main window then replicates the #970 behaviour.

[Tristan Croll]

I've created QTBUG-65640 on the Qt bug tracker.

[Tom Goddard]

Thanks for submitting the Qt bug report.

A few comments on your earlier tests. The windowsize.window_size() ChimeraX call is for setting the size of the graphics pane. But there is no Qt call to do this. So the code instead compares the current size of the graphics pane to the requested size and then requests that the top-level ChimeraX window change by the difference in size. But requesting the top-level to change size may not result in the desired graphics pane size for various reasons, e.g. the top level may not become the requested size because the window system does not have to exactly honor the requested size. Also the graphics pane may not change in size by the same amount as the top level window. At any rate, weirdness is to be expected with windowsize if you push it.

The traceback when you call window_size() in a "graphics update" trigger is not surprising. Graphics update should not do any Qt event handling because those can activate the OpenGL context Qt uses for drawing, replacing the ChimeraX OpenGL context. OpenGL is an ancient dumb design where the current context is in a global variable. Once you switch to not using the ChimeraX context during ChimeraX graphics update you will certainly get an OpenGL error as you report in a previous comment.

[tic20@…]

OK, this is reproducible on the Mac: while dragging a floating widget 
with the mouse, move the mouse cursor into MacOS's top menu bar before 
releasing. This will trigger the failure-to-resize problem in the main 
window, which will persist until you click on the top bar of the 
offending widget.

On 2018-01-10 00:21, ChimeraX wrote:

[Tom Goddard]

Eric, do we set any special floating window flags? Maybe no one has reported this at Qt bugs before because we are doing something unusual that triggers it.

[tic20@…]

It does seem to be new to 5.9.3... you could test it easily enough if you have QtCreator installed on a Mac. Just run the dockwidgets example.

 
 
Tristan Croll
Research Fellow
Cambridge Institute for Medical Research
University of Cambridge CB2 0XY
 

 

[Eric Pettersen]

The only new-ish thing we do is setAllowedAreas on the dock widget to all areas, unless the tool is set to be undockable, in which case we set it to no areas. As Tristan says, it's reproducible outside ChimeraX so I don't think we're doing anything wrong.

--Eric

[goddard@…]

I reproduced Tristan's case where dragging a floating window and releasing with the mouse over the Mac top-of-screen menu bar causes main window resize to fail.  Of course this is a Qt bug.  I'm afraid it may take a few years (literally) for the Qt team to fix it, and since it impacted me in a demo I'm interested if there is any work-around we can come up with.  Seems like there is some state information that puts it into no-resize mode, and we know that by clicking the window frame of the floating window we can return it to working.  So I'd be looking for what that click on the window title bar did and whether I can do the equivalent in software if the window resize code recognizes that the panel resizing has gone belly up.

[Tristan Croll]

Floating widget dragging now works properly in Linux (don't have a Mac with me today to test). There is a new (very minor) bug: on starting ChimeraX the following prints to stderr:

[0316/100736.153880:WARNING:stack_trace_posix.cc(648)] Failed to open file: /tmp/.gl6oZ95W (deleted)
  Error: No such file or directory
[0316/100736.154598:WARNING:stack_trace_posix.cc(648)] Failed to open file: /tmp/ffir9pQtv (deleted)
  Error: No such file or directory

Cosmetic only - functionality isn't affected in any way - and a quick Google says it's already been reported as a PyQt 5.10 bug.

[Tom Goddard]

Resize problem fixed by update to PyQt 5.10.

If you want to report the warning message PyQt problem make a separate ticket -- but probably not useful since we simply have to wait for PyQt or Qt update to fix it.