Super slow performance and video freezing in an eye-tracking experiment

Comments

• sebastiaan

  December 2018

  Hi Helio,

  If I understand correctly, the video plays back smoothly in dummy mode, but things become laggy if you enable the Tobii. Is that right?

  If so, that suggests that some part of the Tobii software slows things down. This could be either the Tobii SDK itself, or the implementation of PyGaze. Looking at the source code, PyGaze indeed continuously collects and logs gaze data from the Tobii, which I imagine can slow things down.

  @Edwin Any thoughts?

  Cheers!
  Sebastiaan

  
  
  Check out SigmundAI.eu for our OpenSesame AI assistant!
  
• Edwin

  December 2018

  Hi all,

  Sounds like an accurate diagnosis, @sebastiaan! Tobii did their own implementation, so you might be able to ask the Devs about it on GitHub, @heliocuve.

  You can open an issue there, and tag them. (Or open the issue, and I will tag them.)

  Cheers,
  Edwin
• heliocuve

  December 2018

  Thank you @sebastiaan and @Edwin for your comments. I will loop in the devs.

  Cheers!
  Helio
• heliocuve

  December 2018

  Hi, again @sebastiaan and @Edwin.

  So, I found out that if I put a blank sketchpad between the video stimuli and the pygaze_log, it seems to solve the lag in the video display, and now the only lag is caused by the pygaze_log as @sebastiaan suggested. Is there a way to specify exactly which variables are to be logged in the pygaze_log file, so that I can potentially reduce the amount of stuff being written to the gaze file, and hopefully this reduces the lag during the pygaze_log period.

  Another question, is it a problem if I move the pygaze_stop_recording to before the pygaze_log? I realized that the gaze data is still being recorded during the lag period where py_gaze logs the variables. So stopping the tracker earlier would perhaps make the file a little bit cleaner? if I have to log a lot of variables?

  Thank you again!
  Cheers!
  Helio
• sebastiaan

  December 2018

  Is there a way to specify exactly which variables are to be logged in the pygaze_log file, so that I can potentially reduce the amount of stuff being written to the gaze file, and hopefully this reduces the lag during the pygaze_log period.

  Yes, you can disable the 'Automatically log all variables' option and then explicitly indicate what you want to log, like so:

  var response [response]
  var condition [condition]
  

  Another question, is it a problem if I move the pygaze_stop_recording to before the pygaze_log? I realized that the gaze data is still being recorded during the lag period where py_gaze logs the variables. So stopping the tracker earlier would perhaps make the file a little bit cleaner? if I have to log a lot of variables?

  I'm not sure if stopping the recording will also prevent log messages from being written. For the EyeLink it would, but for the Tobii it may be different. Why don't you give it a shot?

  Cheers!
  Sebastiaan

  
  
  Check out SigmundAI.eu for our OpenSesame AI assistant!
  
• Edwin

  December 2018

  To give a more specific answer to your second question:

  Before calling the stop_recording function, data is streamed and logged (in a local buffer). When you call it, the buffer is synced to disk (to the log file). By calling the log function, you're writing directly* to the log file (as opposed to adding your message to e.g. a Queue), and thus it doesn't interfere with or is dependent on the active streaming of samples.

  TL;DR You're fine logging outside of start_recording to stop_recording.

  * Small print: It is not actually directly, as it's still writing to a local buffer (which will be wiped during e.g. a crash or loss of power). Once you call stop_recording or close, the data is synced to disk (and thus will persist beyond crash power outage). Fortunately, if OpenSesame crashes, the close function is called automatically, and thus all data should be saved anyways.
• heliocuve

  December 2018

  thanks loads guys! I got this part working smoothly now.

  cheers!
  Helio