vertical blank on LCD monitors

[lawson...@gmail.com]

Hello,

Does anyone know if the Display.WaitForVerticalBlank works the same on LCD monitors as it does on CRT monitors? Likewise, does the "vertical blank" option under the Sync tab of an object's (e.g. a slide) property pages work on LCD monitors?

We have not been able to find any good information on this issue.

LCDs obviously have refresh rates, but the nature of the refreshing seems to be different that that of CRTs, such that it's not necessarily "vertical blanking" per se - one term I have seen is "vertical sync" (v-sync). 

We are using a BENQ RL2455 LCD monitor with an HDMI cable. I have not seen any major errors in onset delays or with the presentation of the program itself, so I'm assuming that the code and settings for vertical blanking that I referenced above work just fine on LCD monitors, but I would like to know this for sure before proceeding! 

Any help would be appreciated - thanks!

Paul  

[David McFarlane]

Paul,

You are correct that "vertical blank" does not literally apply to LCD
displays, as LCD displays have no electron beam to blank out while
moving vertically from the bottom back to the top of the screen. I like
to substitute a term such as "frame refresh" or "video frame synch",
although even "refresh" is a misnomer since LCD pixels do not literally
need refreshing as for CRT displays, where the pixels naturally decay.
Unfortunately we are stuck with the term "vertical blank" as an
historical artifact, much like people still say they "dial" a telephone
even though phones no longer have literal dials (I grew up in the era of
dial telephones). It has become a dead metaphor.

Unlike a CRT, which uses a single electron beam to serially paint the
pixels (left to right, and top to bottom), in principal an LCD could
blast out all pixels at once, and at any time (e.g., only when a pixel
changes). In practice, however, LCD behavior emulates CRT behavior, and
pixels are rewritten at each frame period, from left to right and top to
bottom. I have seen this myself by placing photosensors on LCD displays
and viewing the results on an oscilloscope as I move the photosensors
about the display. In fact, I saw just what has been published, e.g.,
Ghodrati, Morris, & Price (2015), The (un)suitability of modern liquid
crystal displays (LCDs) for vision research, Frontiers in Psychology 6:
1-11. Well worth looking at that.

That said, Display.WaitForVerticalBlank in inline code has become
superfluous for versions of E-Prime that use
DisplayDevice.FlippingEnabled, and may even introduce extra delays --
see
support.pstnet.com/hc/en-us/articles/229362887-NEW-FEATURE-DisplayDevice-FlippingEnabled-18483-
. But do continue to set Onset Sync to "vertical blank" for your
E-Studio visual objects in order to avoid visual tearing, just
substitute a more suitable term in your own mind.

Best,
---------------
David McFarlane
E-Prime® 2.0 training online:
psychology.msu.edu/workshop-and-additional-course/e-prime-introduction-to-programming-computerized-behavioral-tasks
Twitter: @EPrimeMaster (twitter.com/EPrimeMaster)

[lawson...@gmail.com]

Thank you, David! I read the article, but I'm still a bit confused. 

Our program does not use flipping, just the vertical blank coding and settings. The task involves a rotating clockhand which is syncronized with our 60Hz refresh rate (it ticks every 16.666ms). The clock and clockhand are canvas objects that are displayed on a blank slide via inlines. We are getting onset delays in the range of 7-15ms usually, sometimes a bit lower or a bit higher - these delays are for the slide onset, not the onset of the canvas objects. I'm not sure if the canvas objects have delays or how I would make E-DataAid collect such information. 

Do you think we're good to just keep using the vertical blank coding and settings as they are, since we're not using flipping? We would just have to live with the current delays we're getting, I suppose. 

Alternatively, if we were to use flipping, how would I set a Prerelease when the onset delay varies so much from trial to trial? 

Thanks again!

Paul 

[David McFarlane]

Paul,

If you developed this task from scratch using EP2.0.10 or later, and you
did not change the default settings, then you are using display flipping
whether you know it or not. Open up the Experiment Object Properties,
go to the Devices tab, open the Display device, and look at "Flipping
Enabled". If that is set to Yes, then your program uses flipping; if
that setting is No, or does not exist at all, then your program does not
use flipping. (And if you run this under Windows 10, then you must use
flipping, Windows 10 requires that; Windows 10 also requires 32 bit color.)

As explained at
support.pstnet.com/hc/en-us/articles/229362887-NEW-FEATURE-DisplayDevice-FlippingEnabled-18483-
, if your program uses flipping then every Canvas operation that
operates on the Display automatically does a wait for vertical blank, so
if you add Display.WaitForVerticalBlank you end up doing *two* waits for
vertical blank instead of one.

So if your program is set to use flipping, do *not* use
Display.WaitForVerticalBlank in your inline code, but if you really know
that your program does *not* use flipping then do use
Display.WaitForVerticalBlank.

To know more, you could sprinkle your code with Clock.Read to capture
various time points. E.g.,

c.SetAttrib "t.BeforeWaitForVerticalBlank", Clock.Read
Display.WaitForVerticalBlank
c.SetAttrib "t.AfterWaitForVerticalBlank" Clock.Read
myCanvas.LineTo 100, 100
c.SetAttrib "t.AfterCanvasOperation", Clock.Read

would tell you something. For a frame rate of 60 Hz,
(t.AfterWaitForVerticalBlank - t.BeforeWaitForVerticalBlank) should be 0
to 17 ms; with flipping enabled, (t.AfterCanvasOperation -
t.AfterWaitForVerticalBlank) should be 16 or 17 ms; without flipping
enabled, (t.AfterCanvasOperation - t.AfterWaitForVerticalBlank) should
be 0 or 1 ms. I will be interested in your results.

Best,
-- David McFarlane

[lawson...@gmail.com]

Thanks again, David. This information is extremely helpful now and will come in handy in the future as well. 

Yes, I know for sure (but just rechecked to verify) that flipping is not enabled. I was given this program by other researchers, and they had already set flipping enabled to no. So it sounds like we are good to leave the Display.WaitForVerticalBlank in the inlines. 

I like your idea to test those functions. I may well do that.

Paul