If I understand your response correctly, Inquisit already does what it can to prioritize itself
Yes, that is correct.
I'm not sure about the frame-drop issue you are facing given that I know next to nothing about how you've set things up as well as your particular hardware. There are any number of possible points of failure:
- There may be some as yet undisclosed bug in Inquisit. I am not aware of such a bug, but that doesn't mean there isn't one. Unfortunately, one can at best prove the presence of a particular bug, never its absence.
- The graphics system may be doing something funky (driver or hardware issue or some weird interaction), i.e., to any software (including Inquisit) everything may look a-okay, but the (things close to the) metal don't actually do as they say.
- The 60Hz refresh rate suggest you are using some type of flat screen technology (TFT, LCD). All those screens have their own buffer on board. Software instructs OS to display something at a given point in time -> OS hands it to driver / graphics card -> graphics card sends data to display. Unfortunately this is a one-way street. The display may buffer the data for an unknown amount of time, apply some magic to it (think color correction, interleave calculations) and eventually decide to render the data to screen -- or not! Point being, the display actual never reports back to the OS / Software / graphics driver what it did and when.
Now, to start testing, in my Inquisit script I'd first divide my screen canvas into a 6x5 grid (left to right, top to bottom). Then, in the trial's first frame I'd draw to grid coordinate 1/1, third frame draw to 2/1, etc. That would allow me to see -- in context -- if, when and which frames get dropped.
Hope this helps,
~Dave