Slow volume series playback with daily build, 2x faster with devel build

[goddard@…]

The following bug report has been submitted:
Platform:        Darwin-18.7.0-x86_64-i386-64bit
ChimeraX Version: 0.91 (2019-07-20)
Description
The ChimeraX daily build (July 26) plays the neutrophil volume series at 30 frames/second while my development build plays it at 60 frames per second.

The builds are using the same code, only the daily build is signed and uses MACOSX_DEPLOYMENT_TARGET=10.9 (before make install) while my devel build does not sign and sets no deployment target (my macOS 10.14).  Exchanging just the ChimeraX.app/Contents/MacOS/ChimeraX launcher (8 Kbytes unsigned, 16 Kbytes signed) which adds a few python command-line options (-I -m ChimeraX_main) makes the daily build run fast and the devel build slow.  So just the launcher alone is causing the slow behavior.

I used codesign --remove-signature on ChimeraX (reducing its size 16Kb to 8Kb) and the daily build remained slow.  So it is appears the culprit is the deployment target.  That needs testing.  Our download page says the macOS version is tested on macOS 10.12.


Log:
Startup Messages  
---  
warning | 'clip' is a prefix of an existing command 'clipper'  
  
UCSF ChimeraX version: 0.91 (2019-07-20)  
© 2016-2019 Regents of the University of California. All rights reserved.  
How to cite UCSF ChimeraX  

> open /Users/goddard/ucsf/data/neutrophil-vr/neutrophil.cxc

> open c7ch0step221.cmap

Opened map series c7ch0step221.cmap, 110 images, grid size 128,256,151, pixel
0.2,0.2,0.25, shown at level 285, step 1, values float32  

> volume #1 step 1 level 100 color wheat

> open c7ch1step221.cmap

Opened map series c7ch1step221.cmap, 110 images, grid size 128,256,151, pixel
0.2,0.2,0.25, shown at level 101, step 1, values float32  

> volume #2 step 1 level 100 level 350 color #aaaaaaa0 color #ff4040ff

> volume #1 dataCacheSize 20000

> toolshed hide Models

No running tool named "Models"  
No running tool named "Models"  
No running tool named "Models"  




OpenGL version: 4.1 ATI-2.11.20
OpenGL renderer: AMD Radeon Pro 580 OpenGL Engine
OpenGL vendor: ATI Technologies Inc.

[Tom Goddard]

Ticket #2100 about jittery resize also determined by the launcher executable, with the daily build showing smooth resize and the devel build showing jittery resize.

[Tom Goddard]

I compiled ChimeraX launcher.c on our Mac build machine clemens.cgl.ucsf.edu which is running macOS 10.12 without MACOSX_DEPLOYMENT_TARGET set and this still plays the volume series slow (30 frames/sec).

Tried recompiling ChimeraX launcher.c on my development Mac with MACOSX_DEPLOYMENT_TARGET=10.12 on my macOS 10.14 system. This plays the volume series fast (60 frames/second).

So the problem does not seem to be the deployment target.

The daily build machine clemens is using XCode version 9.2 while my development system is using XCode 10.2.1.

Using "otool -l ChimeraX" reports the deployment target as 10.12 in both of the above tests, but reports the sdk to be 10.14 on my devel build, and 10.12 on the clemens builds run on my devel system.

$ otool -l ChimeraX.clemens_build
Load command 9

cmd LC_VERSION_MIN_MACOSX

cmdsize 16
version 10.12

sdk 10.12

$ otool -l ChimeraX.descartes_build
Load command 9

cmd LC_VERSION_MIN_MACOSX

cmdsize 16
version 10.12

sdk 10.14

Would be interesting to try XCode 10 on the build machine. But XCode 10.3 is only available on macOS 10.14.3 and newer and XCode 10.0 is only available on macOS 10.13. So clemens with macOS 10.12 cannot run the newer XCode.

[Tom Goddard]

If turn off waiting for vsync and allow high frame rates

graphics maxFrameRate 1000 waitForVsync false

and then play the neutrophil series with frame rate reported

graphics framerate true
vseries play #1,​2 loop true cache 300

I find both daily build and devel build give 168 - 179 frames/second, both averaging about 172-175 fps.

But if I press the play button on the volume series slider the devel build still gives 60 frames/sec and daily build 30 frames/sec. Not sure what is clamping those rates. The vseries slider command has an option for max_frame_rate but it is not being used. It looks like Qt is somehow limiting the rate with the slider.

The slider code makes the slider move when the play button is pressed by calling an update_slider() method in the MapSeriesSlider class. Commenting out that callback makes the daily and devel build run at the same fast rate (~170 fps) using the slider play button.

So the difference in speed is just that the slider updates limit speed to 30 fps in the daily build and 60 fps in the devel build for unknown reasons. Maybe the macOS SDK is limiting the update rate in some way and uses different limits for sdk 10.12 vs sdk 10.14.

[Tom Goddard]

So the entire cause of the slower playback on daily build vs devel build is because the Qt slider updates at a slower rate. I can see why slider update every frame would limit the rendering rate to 60 frames per second even when I have turned off wait for vsync, because the slider drawing is done by Qt and it is waiting for vsync. (Wait for vsync is only turned off for the ChimeraX rendering opengl context.)

It is still not clear why the daily build limits slider update to 30 frames per second. Even showing just one channel with high threshold so there is almost no surface it is limited to 30 frames per second.

[Tom Goddard]

So the problem is a quirk of Qt update rates.

It will be important to keep in mind that any updates to the Qt gui every frame during VR will limit the frame rate severely. So VR should have not continuous (every frame) desktop gui updates.