# Some questions **URL:** \ **Category:** Support\ **Created:** [April 22, 2024, 3:37pm UTC](https://mworks.discourse.group/t/some-questions/967 "2024-04-22T15:37:34Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![cstawarz](https://yyz1.discourse-cdn.com/flex031/user_avatar/mworks.discourse.group/cstawarz/32/3_2.png) [@cstawarz](https://mworks.discourse.group/u/cstawarz)\ **Post date:** [April 29, 2024, 2:23pm UTC](https://mworks.discourse.group/t/some-questions/967/4 "2024-04-29T14:23:03Z")
Hi Taylor, > Does that mean if I command the queuing of all the stimuli at a non-time sensitive state, the actual update\_display() should not take different amount of time for drawing different number of stimuli? No. Like I said, update\_display does some work for each stimulus, so if there are more stimuli, it will do more work. There’s no way to “pre-perform” that work. FYI, queue\_stimulus does almost nothing – it just adds the stimulus to the list of stimuli to draw. No actual drawing work takes place until update\_display. > The issue I am having right now is that for two protocols, I turn the laser on before update\_display\_and\_wait() with the expectation that the laser would be on about 16ms before the stimulus onset. > > For the protocol with one stimulus (protocol\_LaserAmplitudeWithStim), in the “Stimulus On” state, I turn the laser on, queue the stimulus, and then update\_display\_and\_wait(). The laser onset is about 20ms before the stimulus onset. > > For the protocol with two stimuli (protocol\_2afcLaser), in the 'Stimulus On - Pre-Saccade’ state, I queue all the stimuli first, turn the laser on, and then update\_display\_and\_wait(). However, the laser onset is about 30ms before the stimulus onset for this protocol. I doubt the 10ms difference is all due to the additional stimuli. Even if you normally expect update\_display\_and\_wait to take about 16ms, there’s no guarantee that it’s going to do so. It all depends on where update\_display is invoked relative to the display’s refresh cycle, and you have no control over that. Sometimes the drawing will take place several frames ahead of the actual display update, so update\_display\_and\_wait will wait for 32ms (with a 60Hz display) or longer. Other times, you’ll be drawing for the very next frame, so the wait may be less than a single refresh period. I suspect this variability is the main source of the timing differences you’re seeing. As I’ve said previously, you’re going to have a hard time aligning the laser and stimulus timing with the technique you’re using. I think this issue is an example of that difficulty. I’d really recommend switching to the [alternative technique](https://mworks.discourse.group/t/the-timing-between-turning-laser-on-and-stimulus-on/951/17) that I’ve described elsewhere. Cheers, Chris --- _[View the full topic](https://mworks.discourse.group/t/some-questions/967)._