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