Canvas.Copy is taking too long to complete

[Cognitology]

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-prime at googlegroups.com [mailto:e-prime at googlegroups.com] On Behalf
Of Tamar
Sent: 24. April 2013 08:33
To: e-prime 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+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/-/y5hiddEu-6oJ.
For more options, visit 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/20130424/34a0e5de/attachment.htm>