Canvas.Copy is taking too long to complete

Thu Apr 25 07:24:20 UTC 2013

there must be some interfacing routines we can't 
see in the *.ebs files that differ between v1.? 
and v.2.?, and that e-prime calls when the 
scripts are run??? They both(?) must be 
allowable, and they must call upon different 
routines in e-prime that communicate with the hardware?

At 05:08 PM 25/04/2013, you wrote:
>o.k., here is what I found, following your input:
>
>In any experiment I create in EP1 (in a 
>neighboring lab...), canvas.copy takes under 1 ms.
>In any experiment I create in EP2, canvas.copy takes a whole refresh cycle.
>If I take an experiment created in EP1 and 
>convert it to EP2 - then canvas.copy time is 
>under 1 ms... although nothing in the inline changed...
>How can that be?
>
>
>
>On Thursday, April 25, 2013 8:29:06 AM UTC+3, Peter Quain wrote:
>
>I haven't tested any code examples, but have a 
>lot of data showing canvas.copy in v.1.?.? takes 
>under a ms, supporting David's observations. 
>Perhaps something here is less instant in v2.?, and a bug has been identified?
>
>At 03:19 PM 25/04/2013, you wrote:
>>Thank you both your replies!
>>
>>I am using E-prime 2.0.10, and a CRT iiyama 
>>Vision Master screen, with display resolution
>>of 1024 x 768 and a refresh rate of 100 Hz. My 
>>operating system is windows XP.
>>
>>I'm troubled with this timing issue because my 
>>experiment includes EEG recording, thus the
>>synchronization is terribly important. I need 
>>to send triggers via the parallel port exactly at the
>>onset of each stimulus, or else my EEG signal 
>>might be smeared. Considering that the canvas.copy
>>takes a refresh cycle to complete - I'm not 
>>sure what time ought to be considered the stimulus onset...
>>
>>Anyhow, David, I've tried running your code - 
>>and I get dt's of 13-14ms. Do you think that all the difference
>>between your 0.22ms to my 13-14ms is due to 
>>E-prime1 vs. E-prime2 differences? That's shocking...
>>I get the same results as Michiel for the loop 
>>codes, as puzzling as they are...
>>
>>Thanks again for your help,
>>Tamar
>>
>>
>>
>>
>>On Wednesday, April 24, 2013 4:44:46 PM UTC+3, McFarlane, David wrote:
>>Hmm.  I explored this issue myself three years ago, using EP1 (still my
>>favorite version for this type of exploration).  I just dug up my test
>>program and ran it again on my trusty old XP laptop at home after
>>breakfast, and got times of 0.22 ms even for full screen copies, much as
>>I remember from before (where full screen means 1024 x 768; and yes,
>>that is less than a millisecond).  To be sure, here is the core of my
>>test code:
>>      t0 = clock.readmicrosec
>>      dcnvs.copy cnvs
>>      dt = clock.readmicrosec - t0
>>      msgbox format$( dt/1000, "Standard" ) & " ms"
>>where all variables are defined and initialized earlier as expected
>>(dcnvs is set to Display.Canvas just for notational convenience).
>>Also, I looked at the Canvas.Copy topic in the E-Basic Help -- no
>>evidence that .Copy includes an implicit Display.WaitForVerticalBlank,
>>to the contrary, the code example there includes an explicit
>>Display.WaitForVerticalBlank just before the cnvs.Copy.  I would be
>>*extremely* surprised if Canvas.Copy included a
>>Display.WaitForVerticalBlank, as that would greatly compromise its
>>utility (e.g., when wanting to Copy several segments to an offscreen
>>Canvas before copying the complete result to Display.Canvas).
>>So I do not know how to account for your results.  Mind you, I did all
>>my tests using good-old EP1 with 1024x768 display resolution.  For all I
>>know things changed with the latest EP version, or things get slower
>>with larger display resolutions.  What EP version do you use?  What
>>display resolution?
>>Michiel, I am especially puzzled by your results.  Both of your tests
>>measure the total time to perform a Canvas.Copy and
>>Display.WaitForVerticalBlank, only in different orders.  So you should
>>get the same time for both tests, regardless of whether Canvas.Copy
>>includes its own Display.WaitForVerticalBlank.  What am I missing?
>>Nevertheless, Michiel's advice still stands  -- as long as your program
>>does everything it needs to do within one screen refresh (and assuming
>>that you *do* synchronize visual displays to the screen refresh, as you
>>should), then that is good enough.
>>-----
>>David McFarlane
>>E-Prime training online:
>><http://psychology.msu.edu/Workshops_Courses/eprime.aspx>http://psychology.msu.edu/Workshops_Courses/eprime.aspx 
>>
>>Twitter:  @EPrimeMaster 
>>(<http://twitter.com/EPrimeMaster>twitter.com/EPrimeMaster)
>>/-----------
>>Stock reminder:  1) I do not work for PST.  2) PST's trained staff take
>>any and all questions at
>><http://support.pstnet.com/e%2Dprime/support/login.asp>http://support.pstnet.com/e%2Dprime/support/login.asp 
>>, and they strive
>>to respond to all requests in 24-48 hours, so make full use of it.  3)
>>In addition, PST takes questions at their Facebook page
>>( http://www.facebook.com/pages/Psychology-Software-Tools-Inc/241802160683
>>), and offers several instructional videos there and on their YouTube
>>channel ( http://www.youtube.com/user/PSTNET ) (no Twitter feed yet,
>>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.
>>\-----------
>>
>>Cognitology wrote:
>> > Hi,
>> >
>> > A quick look, but I think that you pretty much nailed it: it can take
>> > quite long to do any canvas operation. Given that your screen refresh
>> > rate presumably isnï¿½t more than 100 Hz (and in any ways, your foveal
>> > vision isnï¿½t), I donï¿½t see the problem? 
>> Indeed, if you were to draw many
>> > things to the main canvas, one after the other, then indeed, it gets to
>> > be a problem, but as long as the only 
>> operation is copying a ï¿½preloadedï¿½
>> > canvas to the shown one, it doesnï¿½t matter all that much. Notice, given
>> > that youï¿½re not using E-Primeï¿½s 
>> stimdisplays, itï¿½s not clear at what
>> > time the stimulus is actually displayed ï¿½ only when itï¿½s done sending
>> > the command. I think itï¿½s generally better for critical timing aspects
>> > of your experiment to avoid canvas as much as possible. Personally, I
>> > think ï¿½critical timingï¿½ is when it concerns a subliminal vs barely
>> > supraliminal prime or some such, for other types of stimuli the 10 ms of
>> > (constant, therefore presumably stimulus independent) delay is of
>> > trivial concern.
>> >
>> >
>> >
>> > Just testing some of it myself, and I get values ranging between 15 and
>> > 17 ï¿½ which is funny, given that my refresh rate is indeed 60, so it
>> > seems a bit like thereï¿½s some sort of 
>> display.waitforverticalblank built
>> > into canvas.copy. Curiously, this:
>> >
>> > For j = 1 To 100
>> >
>> >       DrawFixation ï¿½this is just a custom function drawing a line to
>> > cnvsnext
>> >
>> >       cnvs.copy cnvsnext
>> >
>> >       display.waitforverticalblank
>> >
>> >       debug.print clock.read - clocktime
>> >
>> >       clocktime = clock.read
>> >
>> > Next j
>> >
>> >
>> >
>> > Gives me latencies equal to refresh rates (+- 1 ms).
>> >
>> > Whereas:
>> >
>> >
>> >
>> > For j = 1 To 100
>> >
>> >       DrawFixation ï¿½this is just a custom function drawing a line to
>> > cnvsnext
>> >
>> >       display.waitforverticalblank
>> >
>> > cnvs.copy cnvsnext
>> >
>> >       debug.print clock.read - clocktime
>> >
>> >       clocktime = clock.read
>> >
>> > Next j
>> >
>> >
>> >
>> > Gives me latencies equal to 2xrefresh rates. Somebody with young eyes
>> > should tell us if the first one doesnï¿½t have cutting-off errors,
>> > otherwise Iï¿½d suggest there might be some sort of waitforverticalblank
>> > built into canvas.copy.
>> >
>> > Best,
>> >
>> >
>> >
>> > Michiel Sovijï¿½rvi-Spapï¿½
>> >
>> >
>> >
>> > Helsinki Institute for Information Technology
>> >
>> > Aalto & University of Helsinki
>> >
>> > Finland
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > BTW: notice that using debug.print also incurs a delay (last measured at
>> > 0.7 ms).
>> >
>> >
>> >
>> >
>> >
>> > *From:* e-p... at googlegroups.com [ mailto:e-p... at googlegroups.com] *On
>> > Behalf Of *Tamar
>> > *Sent:* 24. April 2013 08:33
>> > *To:* e-p... at googlegroups.com
>> > *Subject:* Canvas.Copy is taking too long to complete
>> >
>> >
>> >
>> > I'm programming a visual experiment, and suffering from some timing
>> > issues. It seems that the line presenting the stimuli (canvas.copy) is
>> > considerably time consuming: 10-12 ms. I can't figure out the cause for
>> > this delay, and I would appreciate any help...
>> >
>> > Here is the relevant piece of code:
>> >
>> > ====== in an initializing inline script, at the begining of SessionProc:
>> > ======
>> > Set MainCanvas = Display.Canvas
>> > MainCanvas.fillColor = CColor(background_color)
>> > MainCanvas.clear
>> >
>> > For i = 1 To NumStim
>> >    Set StimCanvases(i) = Display.CreateCanvas
>> >
>> >    'define destination rect as center of screen
>> >    destRects(i).Left = Display.XRes/2-stim_w/2
>> >    destRects(i).Top = Display.YRes/2-stim_h/2
>> >    destRects(i).Right = Display.XRes/2+stim_w/2
>> >    destRects(i).Bottom = Display.YRes/2+stim_h/2
>> >
>> >    'define source rect as upper left corner
>> >    srcRects(i).Left = 0
>> >    srcRects(i).Top = 0
>> >    srcRects(i).Right = stim_w
>> >    srcRects(i).Bottom = stim_h
>> >
>> >    'Load the image file
>> >    StimCanvases(i).LoadImage "Stimuli/" & FileNames(i) & ".bmp"
>> >
>> > Next i
>> >
>> > ====== in the inline of TrialProc: =======
>> > Debug.Print "1:" & clock.read
>> > StartTrialTime = clock.read
>> > n = c.GetAttrib("CanvasNum")
>> > c.SetAttrib "TrialStart", StartTrialTime
>> > display.WaitForVerticalBlank
>> > Debug.Print "4:" & clock.read
>> > StartStimTime = clock.read
>> > c.SetAttrib "StimStart", StartStimTime
>> > Debug.Print "5:" & clock.read
>> > mainCanvas.copy StimCanvases(n),srcRects(n),destRects(n)
>> > Debug.Print "6:" & clock.read
>> >
>> >
>> > I've tried a few things:
>> > - to create variables taking the values of
>> > StimCanvases(n),srcRects(n),destRects(n) in the beginning of the trial,
>> > so the mainCanvas.copy line would not need to approach the arrays.
>> > - to present other simple canvases instead of my real stimuli (just a
>> > fixation, for example. or an empty canvas)
>> > - to draw something on the mainCanvas rather than copy a new canvas to
>> > it (e.g. mainCanvas.Circle).
>> >
>> > All of these takes 10-12 ms! (as calculated by subtracting time5 from
>> > time6). The only way I managed to get rid of the delay was to erase the
>> > entire row...
>> >
>> > Am I missing something here?...
>> >
>> > Thanks,
>> > Tamar
>>
>>--
>>You received this message because you are 
>>subscribed to the Google Groups "E-Prime" group.
>>To unsubscribe from this group and stop 
>>receiving emails from it, send an email to e-prime+u... at googlegroups.com.
>>To post to this group, send email to e-p... at googlegroups.com.
>>To view this discussion on the web visit 
>><https://groups.google.com/d/msg/e-prime/-/0DZ5JBsrwGUJ>https://groups.google.com/d/msg/e-prime/-/0DZ5JBsrwGUJ.
>>For more options, visit 
>><https://groups.google.com/groups/opt_out>https://groups.google.com/groups/opt_out.
>>
>>
>
>--
>You received this message because you are 
>subscribed to the Google Groups "E-Prime" group.
>To unsubscribe from this group and stop 
>receiving emails from it, send an email to 
>e-prime+unsubscribe at googlegroups.com.
>To post to this group, send email to e-prime at googlegroups.com.
>To view this discussion on the web visit 
><https://groups.google.com/d/msg/e-prime/-/Vt8fFfvwiJwJ>https://groups.google.com/d/msg/e-prime/-/Vt8fFfvwiJwJ.
>For more options, visit 
><https://groups.google.com/groups/opt_out>https://groups.google.com/groups/opt_out.
>
>

-- 
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To unsubscribe from this group and stop receiving emails from it, send an email to e-prime+unsubscribe at googlegroups.com.
To post to this group, send email to e-prime at googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.linguistlist.org/pipermail/eprime/attachments/20130425/af881ed7/attachment.htm>