Thank you both your replies!<br><br>I am using E-prime 2.0.10, and a CRT iiyama Vision Master screen, with display resolution<br>of 1024 x 768 and a refresh rate of 100 Hz. My operating system is windows XP.<br><br>I'm troubled with this timing issue because my experiment includes EEG recording, thus the<br>synchronization is terribly important. I need to send triggers via the parallel port exactly at the<br>onset of each stimulus, or else my EEG signal might be smeared. Considering that the canvas.copy<br>takes a refresh cycle to complete - I'm not sure what time ought to be considered the stimulus onset...<br><br>Anyhow, David, I've tried running your code - and I get dt's of 13-14ms. Do you think that all the difference<br>between your 0.22ms to my 13-14ms is due to E-prime1 vs. E-prime2 differences? That's shocking...<br>I get the same results as Michiel for the loop codes, as puzzling as they are...<br><br>Thanks again for your help,<br>Tamar<br><br><br><br><br>On Wednesday, April 24, 2013 4:44:46 PM UTC+3, McFarlane, David wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hmm.  I explored this issue myself three years ago, using EP1 (still my 

<br>favorite version for this type of exploration).  I just dug up my test 

<br>program and ran it again on my trusty old XP laptop at home after 

<br>breakfast, and got times of 0.22 ms even for full screen copies, much as 

<br>I remember from before (where full screen means 1024 x 768; and yes, 

<br>that is less than a millisecond).  To be sure, here is the core of my 

<br>test code:

<br>

<br>     t0 = clock.readmicrosec

<br>     dcnvs.copy cnvs

<br>     dt = clock.readmicrosec - t0

<br>     msgbox format$( dt/1000, "Standard" ) & " ms"

<br>

<br>where all variables are defined and initialized earlier as expected 

(dcnvs is set to Display.Canvas just for notational convenience).

<br>

<br>Also, I looked at the Canvas.Copy topic in the E-Basic Help -- no 

<br>evidence that .Copy includes an implicit Display.WaitForVerticalBlank, 

<br>to the contrary, the code example there includes an explicit 

<br>Display.WaitForVerticalBlank just before the cnvs.Copy.  I would be 

<br>*extremely* surprised if Canvas.Copy included a 

<br>Display.WaitForVerticalBlank, as that would greatly compromise its 

<br>utility (e.g., when wanting to Copy several segments to an offscreen 

Canvas before copying the complete result to Display.Canvas).

<br>

<br>So I do not know how to account for your results.  Mind you, I did all 

<br>my tests using good-old EP1 with 1024x768 display resolution.  For all I 

<br>know things changed with the latest EP version, or things get slower 

<br>with larger display resolutions.  What EP version do you use?  What 

display resolution?

<br>

<br>Michiel, I am especially puzzled by your results.  Both of your tests 

<br>measure the total time to perform a Canvas.Copy and 

<br>Display.WaitForVerticalBlank, only in different orders.  So you should 

<br>get the same time for both tests, regardless of whether Canvas.Copy 

includes its own Display.WaitForVerticalBlank.  What am I missing?

<br>

<br>Nevertheless, Michiel's advice still stands  -- as long as your program 

<br>does everything it needs to do within one screen refresh (and assuming 

<br>that you *do* synchronize visual displays to the screen refresh, as you 

should), then that is good enough.

<br>

<br>-----

<br>David McFarlane

<br>E-Prime training online: 

<br><a href="http://psychology.msu.edu/Workshops_Courses/eprime.aspx" target="_blank">http://psychology.msu.edu/<wbr>Workshops_Courses/eprime.aspx</a>

<br>Twitter:  @EPrimeMaster (<a href="http://twitter.com/EPrimeMaster" target="_blank">twitter.com/EPrimeMaster</a>)

<br>

<br>/-----------

<br>Stock reminder:  1) I do not work for PST.  2) PST's trained staff take 

<br>any and all questions at 

<br><a href="http://support.pstnet.com/e%2Dprime/support/login.asp" target="_blank">http://support.pstnet.com/e%<wbr>2Dprime/support/login.asp</a> , and they strive 

<br>to respond to all requests in 24-48 hours, so make full use of it.  3) 

<br>In addition, PST takes questions at their Facebook page 

<br>(<a href="http://www.facebook.com/pages/Psychology-Software-Tools-Inc/241802160683" target="_blank">http://www.facebook.com/<wbr>pages/Psychology-Software-<wbr>Tools-Inc/241802160683</a> 

<br>), and offers several instructional videos there and on their YouTube 

<br>channel (<a href="http://www.youtube.com/user/PSTNET" target="_blank">http://www.youtube.com/user/<wbr>PSTNET</a> ) (no Twitter feed yet, 

<br>though).  4) If you do get an answer from PST staff, please extend the 

courtesy of posting their reply back here for the sake of others.

<br>\-----------

<br>

<br>

<br>Cognitology wrote:

<br>> Hi,

<br>> 

<br>> A quick look, but I think that you pretty much nailed it: it can take 

<br>> quite long to do any canvas operation. Given that your screen refresh 

<br>> rate presumably isn�t more than 100 Hz (and in any ways, your foveal 

<br>> vision isn�t), I don�t see the problem? Indeed, if you were to draw many 

<br>> things to the main canvas, one after the other, then indeed, it gets to 

<br>> be a problem, but as long as the only operation is copying a �preloaded� 

<br>> canvas to the shown one, it doesn�t matter all that much. Notice, given 

<br>> that you�re not using E-Prime�s stimdisplays, it�s not clear at what 

<br>> time the stimulus is actually displayed � only when it�s done sending 

<br>> the command. I think it�s generally better for critical timing aspects 

<br>> of your experiment to avoid canvas as much as possible. Personally, I 

<br>> think �critical timing� is when it concerns a subliminal vs barely 

<br>> supraliminal prime or some such, for other types of stimuli the 10 ms of 

<br>> (constant, therefore presumably stimulus independent) delay is of 

<br>> trivial concern.

<br>> 

<br>>  

<br>> 

<br>> Just testing some of it myself, and I get values ranging between 15 and 

<br>> 17 � which is funny, given that my refresh rate is indeed 60, so it 

<br>> seems a bit like there�s some sort of display.waitforverticalblank built 

<br>> into canvas.copy. Curiously, this:

<br>> 

<br>> For j = 1 To 100

<br>> 

<br>>       DrawFixation �this is just a custom function drawing a line to 

<br>> cnvsnext

<br>> 

<br>>       cnvs.copy cnvsnext

<br>> 

<br>>       display.waitforverticalblank

<br>> 

<br>>       debug.print clock.read - clocktime

<br>> 

<br>>       clocktime = clock.read

<br>> 

<br>> Next j

<br>> 

<br>>  

<br>> 

<br>> Gives me latencies equal to refresh rates (+- 1 ms).

<br>> 

<br>> Whereas:

<br>> 

<br>>  

<br>> 

<br>> For j = 1 To 100

<br>> 

<br>>       DrawFixation �this is just a custom function drawing a line to 

<br>> cnvsnext

<br>> 

<br>>       display.waitforverticalblank

<br>> 

<br>> cnvs.copy cnvsnext

<br>> 

<br>>       debug.print clock.read - clocktime

<br>> 

<br>>       clocktime = clock.read

<br>> 

<br>> Next j

<br>> 

<br>>  

<br>> 

<br>> Gives me latencies equal to 2xrefresh rates. Somebody with young eyes 

<br>> should tell us if the first one doesn�t have cutting-off errors, 

<br>> otherwise I�d suggest there might be some sort of waitforverticalblank 

> built into canvas.copy.

<br>> 

<br>> Best,

<br>> 

<br>>  

<br>> 

<br>> Michiel Sovij�rvi-Spap�

<br>> 

<br>>  

<br>> 

<br>> Helsinki Institute for Information Technology

<br>> 

<br>> Aalto & University of Helsinki

<br>> 

<br>> Finland

<br>> 

<br>>  

<br>> 

<br>>  

<br>> 

<br>>  

<br>> 

<br>> BTW: notice that using debug.print also incurs a delay (last measured at 

<br>> 0.7 ms).

<br>> 

<br>>  

<br>> 

<br>>  

<br>> 

<br>> *From:* <a href="javascript:" target="_blank" gdf-obfuscated-mailto="uOHVWIFM1isJ">e-p...@googlegroups.com</a> [mailto:<a href="javascript:" target="_blank" gdf-obfuscated-mailto="uOHVWIFM1isJ">e-p...@googlegroups.<wbr>com</a>] *On 

<br>> Behalf Of *Tamar

<br>> *Sent:* 24. April 2013 08:33

<br>> *To:* <a href="javascript:" target="_blank" gdf-obfuscated-mailto="uOHVWIFM1isJ">e-p...@googlegroups.com</a>

<br>> *Subject:* Canvas.Copy is taking too long to complete

<br>> 

<br>>  

<br>> 

<br>> I'm programming a visual experiment, and suffering from some timing 

<br>> issues. It seems that the line presenting the stimuli (canvas.copy) is 

<br>> considerably time consuming: 10-12 ms. I can't figure out the cause for 

> this delay, and I would appreciate any help...

<br>> 

<br>> Here is the relevant piece of code:

<br>> 

<br>> ====== in an initializing inline script, at the begining of SessionProc: 

<br>> ======

<br>> Set MainCanvas = Display.Canvas

<br>> MainCanvas.fillColor = CColor(background_color)

<br>> MainCanvas.clear

<br>> 

<br>> For i = 1 To NumStim

<br>>    Set StimCanvases(i) = Display.CreateCanvas

<br>> 

<br>>    'define destination rect as center of screen

<br>>    destRects(i).Left = Display.XRes/2-stim_w/2

<br>>    destRects(i).Top = Display.YRes/2-stim_h/2

<br>>    destRects(i).Right = Display.XRes/2+stim_w/2

<br>>    destRects(i).Bottom = Display.YRes/2+stim_h/2

<br>>    

<br>>    'define source rect as upper left corner

<br>>    srcRects(i).Left = 0

<br>>    srcRects(i).Top = 0

<br>>    srcRects(i).Right = stim_w

<br>>    srcRects(i).Bottom = stim_h

<br>>    

<br>>    'Load the image file

<br>>    StimCanvases(i).LoadImage "Stimuli/" & FileNames(i) & ".bmp"

<br>>    

<br>> Next i

<br>> 

<br>> ====== in the inline of TrialProc: =======

<br>> Debug.Print "1:" & clock.read

<br>> StartTrialTime = clock.read

<br>> n = c.GetAttrib("CanvasNum")

<br>> c.SetAttrib "TrialStart", StartTrialTime

<br>> display.WaitForVerticalBlank

<br>> Debug.Print "4:" & clock.read

<br>> StartStimTime = clock.read

<br>> c.SetAttrib "StimStart", StartStimTime

<br>> Debug.Print "5:" & clock.read

<br>> mainCanvas.copy StimCanvases(n),srcRects(n),<wbr>destRects(n)

<br>> Debug.Print "6:" & clock.read

<br>> 

<br>> 

<br>> I've tried a few things: 

<br>> - to create variables taking the values of 

<br>> StimCanvases(n),srcRects(n),<wbr>destRects(n) in the beginning of the trial, 

> so the mainCanvas.copy line would not need to approach the arrays.

<br>> - to present other simple canvases instead of my real stimuli (just a 

<br>> fixation, for example. or an empty canvas)

<br>> - to draw something on the mainCanvas rather than copy a new canvas to 

<br>> it (e.g. mainCanvas.Circle).

<br>> 

<br>> All of these takes 10-12 ms! (as calculated by subtracting time5 from 

<br>> time6). The only way I managed to get rid of the delay was to erase the 

<br>> entire row...

<br>> 

<br>> Am I missing something here?...

<br>> 

<br>> Thanks,

<br>> Tamar

<br>

<br></blockquote>

<p></p>

-- <br />

You received this message because you are subscribed to the Google Groups "E-Prime" group.<br />

To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+unsubscribe@googlegroups.com.<br />

To post to this group, send email to e-prime@googlegroups.com.<br />

To view this discussion on the web visit <a href="https://groups.google.com/d/msg/e-prime/-/0DZ5JBsrwGUJ">https://groups.google.com/d/msg/e-prime/-/0DZ5JBsrwGUJ</a>.<br />

For more options, visit <a href="https://groups.google.com/groups/opt_out">https://groups.google.com/groups/opt_out</a>.<br />

 <br />

 <br />