losing focus during longer sleeps or slide durations on Windows

kolfers

Hi all,

I noticed that when using clock.sleep() upwards of 6-7 seconds or when setting a slide duration of similar size, Opensesame (3.3.12) seems to lose focus when in fullscreen:

• A windows mouse cursor (usually in the circle loading animation) shows up
• The entire desktop and/or the taskbar flash once or multiple times

I'm seeing this on an up-to-date Windows 10 machine, and tested with all the back ends, with a multi-monitor setup:

• Slide with keypress as duration: no issue
• Slide with 10 second duration: loses focus
• Slide with 0 duration followed by 10 second keyboard item: no issue
• Slide with 0 duration followed by a 10 second clock.sleep(): loses focus
• Slide with 0 duration followed by a 10 second while loop: no issue
• Feedback item with 10 second duration: loses focus
• Variations of the above where clock.sleep() is replaced with any other blocking function that takes longer than 6-7 seconds: loses focus

Is this expected behavior? And if so, is there anything I can do about it? While I can often replace a sleep with a while loop, in some cases I'm calling a blocking function that needs to wait for a response (i.e. from external triggers) and the same problem occurs.

Kind regard,

Kerwin

Newexperiment.osexp

sebastiaan

Hi @kolfers ,

Thanks for reporting this! I actually don't see this behavior myself on my Windows 11 test system, but my guess is that this is a subtle difference between operating systems. It's easy to see where it comes from though: when a sleep occurs for a while, this blocks the application; the operating system probably interprets this as the application being unresponsive and notifies the user of this by flashing the taskbar etc.

For now, you can try something like the script below. This should be in the prepare phase of an inline_script at the start of the experiment. It replaces the regular sleep() function with a function that, for longer durations, starts by looping before ending with a regular sleep. The question is whether this is enough to avoid the application from seeming unresponsive to the operating system. Because I don't experience the issue at all, I can't test that right now, but maybe you can let me know?

def non_blocking_sleep(duration):
    # For short(ish) durations, just execute a regular sleep
    if duration < 5000:
        clock._orig_sleep(duration)
        return
    print('non-blocking sleep')
    # For longer durations, start by looping
    t0 = clock.time()
    for t in clock.loop_for(duration - 1000, throttle=100):
        # I'm not sure an empty loop is enough to make the process seem
        # response to the operating system. If not, a Keyboard.get_key() with
        # a timeout of 0 or something similar may be necessary.
        pass
    # And then sleep for the remainder of the duration to end up with
    # exactly the intended sleep duration
    clock._orig_sleep(duration - clock.time() + t0)

clock._orig_sleep = clock.sleep
clock.sleep = non_blocking_sleep

-- Sebastiaan