ProPixx and queue image

Hello, we have been trying to use PTB with our ProPixx projector running at 1440 Hz. We have found that there is some sort of timing bottleneck in the “queueimage” PTB function.

We ran some of the demos on a Linux machine. For demo 2 (no queueimage), the average time for 12 frames is 0.0017s. For demo 4 (has queueimage), the average time for 12 frames is 0.0145s. For demo 4 plus gabors, the average time for 12 frames is 0.0146s.

The frame rate is 120 Hz, and the way the ProPixx works is that you compile 12 frames together for each 120 Hz frame, and then the projector plays each of those 12 frames at 1440 Hz. But for some reason queueimage is dropping one frame each 120 Hz frame, destroying the timing. We haven’t looked into the internals of the queueimage function. If we sequence the frames ourselves without using the queueimage function, the timing works fine. It is just more convenient to use queueimage.



Hi Keith,
and welcome back! Keith is one of the very few good and supportive people in our user group, unfortunately a tiny minority. His generous donation of an only slightly used MacBookPro 2010 over ten years ago is what helped a lot to keep Psychtoolbox alive during the last decade. Without him, at least the macOS version of PTB would have died over ten years ago. “twisty” as I named that machine, despite some components failing over the years due to old age, provided great service until last April when its battery bloated up and died. I still hope to revive him at some point for some light use if i find the time to repair it without setting myself or the flat on fire.

Back to your question: I don’t know what demo 2 or 4 are? The
PropixxImageUndistortionThrowaway.m is the only demo shipping with PTB, and its help text has various performance tips, although some of them are outdated by now, given the demo has not been updated in many years.

That every 12th ‘QueueImage’ call would take longer is normal, as only every 12th frame will trigger a ‘Flip’ and incur way more processing or blocking on OpenGL bufferswaps.

But the demo “as is” was able to run stable in the year 2015 at 1440Hz on graphics hardware from 2010 with a Ubuntu Linux 14.04-LTS from 2014. Surely it should run as well or better on present hardware.

I’d need more details of your hardware and software setup, display configuration etc. and demo code. If you use a recommended graphics card with open-source graphics drivers on Linux, ie. not a NVidia card, then flipmethod 2 in that demo shows the most efficient way of presenting: No blocking flips during presentation, and collecting the timing samples at the end of a presentation sequence or trial via the ‘GetTimingSamples’ function. Also some other tricks to increase parallelism between cpu and gpu and avoid blocking whenever possible. flipmethod 1 also works on less advanced operating systems like Windows, but is less efficient, flipmethod 0 is the default and least efficient / most likely to block every 12th stimulus frame.

More info needs more details.