Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Supported by

If opengl is set to 'False', is code execution on hold?

edited January 25 in Expyriment


I'm looking into the exact timing of visual stimulus presentation etc. at the moment. As I understand it, by default, expyriment blocks code execution until the stimulus is fully present on the screen (i.e. until a complete frame is presented). Would it also block code execution, if I set opengl to False?

Edit: I'm using expyriment 0.6.3 for this project


  • No. OpenGL is crucial for that. And even then I would suggest to check with the test suite.

    Thanked by 1peterk

    Florian Krause (Developer)

  • Okay, so if open gl is turned off, it will update the screen at any state of the vertical retrace and just go on, with the code immediately. If it is on, it will wait until the retrace starts at the upper left, refresh the screen, and then go on with the code?
    Sorry this sounds like the same question once more but I wanna be sure I got it correctly ^^

  • The variable expyriment.control.defaults.open_gl can have the following values:

        0/False = no OpenGL (no vsync / no blocking)
        1       = OpenGL (vsync / no blocking)
        2       = OpenGL (vsync / blocking)
        3       = OpenGL (vsync / alternative blocking)

    Only 2 and/or 3 will block the execution of the present method until the image is actually started to be drawn on the display. It is important to always check if this actually works on your hardware (and which of the two settings will work). To do so, please do the visual presentation test in the test suite (
    In the other two cases (0 and 1), the method will return immediately. For 0, the video card will draw the new stimulus wherever the vertical retrace is. Whether this will happen immediately cannot be guaranteed, as it is left to the video card to decide when to start drawing. For 1, the video card will still sync with the vertical retrace, but again, you will not know when that is.

    Thanked by 1peterk

    Florian Krause (Developer)

  • edited January 28

    So I've tested both (open gl 0 vs. 2) and ran a number of trials and collected the stimulus presentation times of 2 stimuli (A and B ) from the xpe file. Attached graphic shows the Inter-Stimulus Intervals (time B - time A), which were set to 1014 ms (no multiple of 1000/60). I would expect that open GL=0 should give me an ISI of 1014, and openGL=2 to give me an ISI of 61/60 ~ 1020 ms.
    Both open GL options seem to present the stimuli at ~1020 ms which is in line with waiting for a vertical synchronization.

    Am I overlooking something or is everything just right, even when I turn open GL off?

    [I've ran the test suite, it got me 60.02 Hz (which is approx. correct), these horizontal dot patterns and double buffering - seems to me quite right all in all. And I've checked with the IT people of my department, that graphic card settings force V-Sync.]

  • This is difficult to say without seeing the exact script you used.

    The testsuite results should be a more controlled benchmark. When you just start the test suite, a good result would be if none of the results are in red colour. Preferably there is also no yellow. It will tell you the expected delays and the unexpected delays. Expected delays will be a multiple of the refresh rate when OpenGL is on. When you start the testsuite after you switched off OpenGL, then the results should differ.

    Florian Krause (Developer)

  • Hmm, seems like they dont... Here's what I've done:

    in terminal
    $import expyriment

    => 1) Visual stimulus presentation

    • horizontal dots like in attached figure [no color but looked more similar to the green dots in the example]
    • correct estimation of refresh rate
    • only left square blinked.

    in the protocol:
    testsuite_visual_timing_actual: all numbers are multiples of 1000/60
    testsuite_visual_timing_todo: some non-patterned numbers.

    Then back in terminal:
    ... Same procedure as above; same results.

  • edited January 28

    Alright I found the solution.

    to really turn off opengl, it takes the command with an underscore, i.e. $expyriment.control.defaults.open_gl=0. Then it doesnt work anymore. The way I did it, apparently it doesnt turn opengl really off.
    Interestingly, using the command without an underscore solves the error reported elsewhere, which was the reason why I thought I had to turn opengl off in the first place.

    Now I can keep opengl on and everything is perfect. Thanks for your help :)

  • Yes indeed, there was a small type in your code snippet. Glad to hear that it works now!
    (The other error you are referring to seems unrelated).

    Florian Krause (Developer)

Sign In or Register to comment.