OpenGL windows become unresponsive without error measasge

[Tristan Croll]

Not sure what's happened here - Just messing about with visualisations (to do with analysing CASP models) when the OpenGL windows (both main and side view) stopped responding. Menus and shell are still responsive - I'll leave the session open in case you want me to query anything.

[goddard@…]

Does the graphics restart command make th graphics work?

[tic20@…]

Afraid not.

On 2018-11-26 16:28, ChimeraX wrote:

[goddard@…]

Does graphics framerate true report anything in the status line?

Can you use Help / Report a Bug so I can see your log of commands.

[tic20@…]

For a while the last drawn image was simply static on the display, but 
resizing the window wiped it to black. The mouse still does something:

session.view.camera.position.origin()
Out[229]: array([-20.37782743,  -2.60235738, 290.57206025])

(after scrolling in the main window)

session.view.camera.position.origin()
Out[230]: array([  8.84902188,   1.46396408, 269.07875643])

Nothing unusual about what I was doing - changing cartoon styles, 
changing bond radii, hiding and showing models, ...

On 2018-11-26 16:36, ChimeraX wrote:

[tic20@…]

Submitted.

'graphics framerate true' is reporting:

29.5 frames per second, draw 18%, new_frame 0%, atomic_check_for_changes 
0%, drawing_change 0%, clip 0%

On 2018-11-26 16:41, ChimeraX wrote:

[goddard@…]

Strange.  Either the Qt timer stopped firing, unlikely, or maybe redraw is blocked, or it is rendering and nothing is shown due to a graphics driver issue.  To check if it is blocked look at core/updateloop.py.  There is a variable in the update loop class that is an integer with values greater than zero blocking redraw, maybe called something like block_count.  I am not at a computer so can’t check.  The updater instance is something like session.updateloop.  I can give you better info in a few hours when I get to work.

[goddard@…]

Oh.  That is odd.  So ChimeraX claims it is rendering only we don’t see anything.  Could be graphics driver problem, or somehow our opengl state got munged.

[goddard@…]

Does setting background color to white work?  Does switching between mono and ortho camera help?  Does the view command centering the models fix it?  Does info bounds report a reasonable bounding box for the scene?

[tic20@…]

session.update_loop._block_redraw_count returns -1.

I started a new ChimeraX session to do the same job I was in the middle 
of, and it's performed just fine.

Have to head off home soon, but will leave the session running in case 
you have anything else you'd like me to query in the morning.

On 2018-11-26 16:54, ChimeraX wrote:

[tic20@…]

Does setting background color to white work?  No
Does switching between mono and ortho camera help?  No
Does the view command centering the models fix it? No
Does info bounds report a reasonable bounding box for the scene? Yes: 
Scene bounds 94.6,-0.153,170 to 128,31.5,218


On 2018-11-26 17:01, ChimeraX wrote:

[goddard@…]

Ok, just a couple more ideas.  Try the “windowsize” command to see that it reports a reasonable window size (not 0).  Also try menu Tools / General / Side View to see if it will render the side view graphics.

Would also be good to use Help / Report a Bug so we know exactly what commands were executed.

The main clues have been the graphic frame rate ~30 means ChimeraX is rendering.  The fact that not even the background color can be changed means either the OpenGL state is goofed up some how (rendering say only to a framebuffer instead of the screen, or wrong draw buffer target), or the graphics driver is goofed up.

If there are no more clues I will close this and we’ll see if it ever happens again.

[Tristan Croll]

Will check the windowsize command tomorrow. Side View was open, and stopped rendering at the same time the main view did.

[Tom Goddard]

Log output is in ticket #1479. Does not suggest any cause, although Tristan notes there were ~500 models opened and closed in the same session before graphics drawing ceased.

[tic20@…]

To be fair, I *was* asking quite a bit of it. The attached image was 
created earlier in the same session, overlaying all (a few hundred) 
submitted models for a given target. The bottom end of the CASP 
submissions can get a little funky.

On 2018-11-26 21:54, ChimeraX wrote:

T0963-D5_all_models_overlay.jpg​

[tic20@…]

Added by email2trac

[tic20@…]

`windowsize` reports a perfectly reasonable 1274x961. I'll go ahead and 
close the session now. Will let you know if it ever happens again.

On 2018-11-26 18:44, ChimeraX wrote:

[Tom Goddard]

All indications were that ChimeraX was rendering graphics, but it did not appear on-screen. This is likely an opengl problem, either with the driver or with the ChimeraX OpenGL state.

Not enough clues to debug.