Object Execution
A Simple Overview
An object’s execution occurs from its StartTime until its StopTime. OnsetTime is defined as the timestamp, in milliseconds, from the start of the experiment to when the object’s onset action, in this case drawing the display to the screen, begins. OffsetTime is defined as the timestamp, in milliseconds, from the start of the experiment to when the object’s offset action, in this case stop execution, begins. The duration of an object’s execution is the difference between the OffsetTime and the OnsetTime. Figure 1 below illustrates the TimeAudit variables for a single object executing in Event Mode.
Figure 1. Simplified timing diagram for an E-Prime Object
OnsetTime is a critical item to understand, so we’ll examine it a bit further here. For a display object, the OnsetTime provides a timestamp of the exact time at which the display object begins to draw. Monitors are always drawn starting with the upper left-hand corner of the monitor, and OnsetTime reflects this event. In other words, OnsetTime is the time immediately after the vertical refresh occurs and the draw command begins to execute. Note that this process describes how the monitor operates; E-Prime can also handle special situations where the video cards provide information in a different manner.
E-Prime can NOT tell you when each component of the display is placed on the screen. (Note that we are describing the typical behavior for CRT and LCD monitors; DLP and other styles of monitors may behave differently.) For example, consider a fixation cross in the center of the screen. If the monitor has a refresh rate of 60Hz, then it takes 16.6666ms for all of the pixels that comprise the display to have their information updated. In the case of a CRT display, this means refreshed with the electron gun; in the case of an LCD display, this typically means resetting the video hardware to prepare for the next set of data. Therefore, any information that is displayed in the center of the screen would appear approximately halfway through the screen update or approximately 8 ms after the object’s OnsetTime. As a final note about this simplified view of object execution, notice that the actual Duration that is shown in the figure is defined as the difference between the OffsetTime and the OnsetTime. This is NOT the same value that is logged in the data file as <object>.Duration. The Duration variable that is logged in the data file is the requested duration that is specified in the Duration field on the Duration/ Input tab. However, E-Prime provides an easy way to obtain a close approximation to how long a stimulus appeared on screen. The OnsetToOnset time, which indicates how much time elapsed from the Onset of the current object to the onset time of the next object, can be logged in the data file by utilizing the TimeAudit feature (but see TIMING: Time Audit: Confirming Accurate Timing [22864] and TIMING: Time Audit [22865] for important cautions regarding the interpretation of this value).
Object Execution: a more Complete Description
A more complete picture of object execution, reflecting important actions prior to an object’s OnsetTime, is shown in Figure 2. This example continues with Event Mode timing.
Figure 2. Event Mode with no PreRelease
Figure 2 introduces several new object properties: ActionDelay and ActionTime. As was stated above, the OnsetTime is the timestamp at which the object begins its action. For a visual display object, it represents the time at which the object begins to execute its draw command; for a SoundOut object, it is the time at which the object begins to play the sound file. More precisely, the OnsetTime represents the timestamp at which E-Prime passes off execution for stimulus presentation to the appropriate hardware’s drivers (e.g. the video or sound card) and to the operating system. The ActionTime represents the timestamp at which the hardware’s driver returns control back to E-Prime.
Typically, the difference between the OnsetTime and the ActionTime will be less than 1 millisecond. Any cases where they are not within a millisecond of each other may signal a potential problem with your hardware device. Therefore, when you check your pilot data, include an evaluation of ActionDelay, to ensure that no significant delays are occurring.
OnsetDelay and TargetOnsetTime: OnsetDelay is the difference between the TargetOnsetTime and the OnsetTime. The TargetOnsetTime is a timestamp calculated internally by E-Prime at the conclusion of the prior object. With a discrete trial paradigm, OnsetDelay should be as small as possible1.
1In some cases, OnsetDelay can be negative. This can occur when using RefreshAlignment. See TIMING: Obtaining Accurate Timing and Timing Best Practices [22855]
See Also:
Comments
1 comment
This article says, "An object’s execution occurs from its StartTime until its StopTime." In fact, there is no StopTime property -- I suspect you mean FinishTime.
The article then goes on to say, "The duration of an object’s execution is the difference between the OffsetTime and the OnsetTime." This statement explicitly conflicts with the earlier statement.
The correct statement would be, "The duration of an object’s execution is the difference between the FinishTime and the StartTime", although that is hardly a value that users care about explicitly, but do care about in relation to PreRelease.
By contrast, the difference between the OffsetTime and the OnsetTime simply provides the duration from the onset action of an object to its offset action, yet another value that users hardly care about.
Users do care about the actual duration of presentation of a visual object, which, as the article says, is given by OnsetToOnsetTime (i.e., the difference between the OnsetTime of the following object and the OnsetTime of the current object). Although this also assumes that ClearAfter is set to false, otherwise the duration of presentation would come to OnsetTime - OffsetTime, which could result in surprises when using PreRelease (thus ClearAfter is now deprecated).
Please see also https://groups.google.com/d/topic/e-prime/OeiZ00V9SRc.
I suspect this article has many more errors. To be fair, it is hard to express all these timing issues correctly (I speak from experience). Users should be wary of trusting this article.
Please sign in to leave a comment.