VSYNC for LCD?

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

Can someone explain to me how the meaning of the vsync interrupt for
an LCD monitor will differ from that on a CRT?

Does an LCD update it's pixel values in the same way (timing-wise) as
a CRT? IE. does it paint the screen line by line and then issue the
vsync to mark the start of a blanking period?

And would the updating technique change if you are using DVI-D vs.
VGA?

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

"Chris G" <cgrebeld@hotmail.com> wrote in message
news:74c403e9.0406040707.779a372d@posting.google.com...
> Can someone explain to me how the meaning of the vsync interrupt for
> an LCD monitor will differ from that on a CRT?
>
> Does an LCD update it's pixel values in the same way (timing-wise) as
> a CRT? IE. does it paint the screen line by line and then issue the
> vsync to mark the start of a blanking period?
>
> And would the updating technique change if you are using DVI-D vs.
> VGA?

Taking the last question first - no, not really. The LCD panel itself
sees pretty much the same data at the same timing in either case; once
the analog video signal from the VGA input is A/D converted, the
contents of the video data streams (assuming the same timing in both
cases) should ideally be indistinguishable. What difference there IS
between the "analog" and "digital" inputs almost all comes from errors
in the sampling clock generation in the A/D conversion process, owing
to the fact that the analog video signal we have today doesn't carry
any pixel clock information along with it (this may change in the future).

VSYNC does not mark the start of the vertical blanking period in
either case - it typically occurs one to three lines time into the blanking
period. It is difficult to unambiguously determine the start of the
blanking periods in analog video (at least per the PC standards), as
there is no difference between the "blank" and "black" levels in the
video (this is not the case in "TV" video). In the digital standards,
such as DVI, a separate "display enable" signal is produced which
is effectively the blanking. VSYNC in both cases means "get ready
to start the next frame; in CRT displays, it triggers the vertical retrace,
while in others it basically is used just to reset the internal counters
in the panel controllers such that the next valid video data received
is written to the first line.

Since the non-CRT types don't need a "retrace time" as such - it
doesn't take much time to reset the thing to writing the first line of
the panel - there has been a recent move to generate "reduced
blanking" timings for these (which affects both the horizontal and
vertical blanking intervals - most of the blanking time is actually in
the horizontal). The reason for this is to permit slower pixel rates
for a given pixel format and refresh rate combination - often as
much as 20% or more lower than the "CRT" timing requires.

LCDs aren't exactly updated the same way as a CRT - they are
NOT written one pixel at a time, although the data comes into the
panel more or less in this manner. What typically happens is that
an entire line of pixels is moved into the row drivers, and then that
entire row (the equivalent of a CRT "scan line") is written at once.
This is all under the control of the internal panel electronics, though,
so you don't have to worry about it in terms of how you drive the
panel.

Bob M.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

Thanks for the explanations, I have some follow up questions:

I want to determine as precisely as possible, when an image is
actually displayed on the LCD. If the software is set to 'wait on
vsync' before it writes into the video buffer, then I should be able
to predict the time when the image is displayed, if I know what
scanlines the image is on, when the vsync happened, and the pixel
response time.

Could I do this with the DVI 'display-enable' signal you mention?
Could you tell me what pin(s) you are talking about?

http://sunsolve.sun.com/handbook_pub/Devices/Monitor/MONITOR_Connector_Pinouts.html



Chris G


"Bob Myers" <nospamplease@address.invalid> wrote in message news:<9U1wc.2991$hg2.1628@news.cpqcorp.net>...
> "Chris G" <cgrebeld@hotmail.com> wrote in message
> news:74c403e9.0406040707.779a372d@posting.google.com...
> > Can someone explain to me how the meaning of the vsync interrupt for
> > an LCD monitor will differ from that on a CRT?
> >
> > Does an LCD update it's pixel values in the same way (timing-wise) as
> > a CRT? IE. does it paint the screen line by line and then issue the
> > vsync to mark the start of a blanking period?
> >
> > And would the updating technique change if you are using DVI-D vs.
> > VGA?
>
> Taking the last question first - no, not really. The LCD panel itself
> sees pretty much the same data at the same timing in either case; once
> the analog video signal from the VGA input is A/D converted, the
> contents of the video data streams (assuming the same timing in both
> cases) should ideally be indistinguishable. What difference there IS
> between the "analog" and "digital" inputs almost all comes from errors
> in the sampling clock generation in the A/D conversion process, owing
> to the fact that the analog video signal we have today doesn't carry
> any pixel clock information along with it (this may change in the future).
>
> VSYNC does not mark the start of the vertical blanking period in
> either case - it typically occurs one to three lines time into the blanking
> period. It is difficult to unambiguously determine the start of the
> blanking periods in analog video (at least per the PC standards), as
> there is no difference between the "blank" and "black" levels in the
> video (this is not the case in "TV" video). In the digital standards,
> such as DVI, a separate "display enable" signal is produced which
> is effectively the blanking. VSYNC in both cases means "get ready
> to start the next frame; in CRT displays, it triggers the vertical retrace,
> while in others it basically is used just to reset the internal counters
> in the panel controllers such that the next valid video data received
> is written to the first line.
>
> Since the non-CRT types don't need a "retrace time" as such - it
> doesn't take much time to reset the thing to writing the first line of
> the panel - there has been a recent move to generate "reduced
> blanking" timings for these (which affects both the horizontal and
> vertical blanking intervals - most of the blanking time is actually in
> the horizontal). The reason for this is to permit slower pixel rates
> for a given pixel format and refresh rate combination - often as
> much as 20% or more lower than the "CRT" timing requires.
>
> LCDs aren't exactly updated the same way as a CRT - they are
> NOT written one pixel at a time, although the data comes into the
> panel more or less in this manner. What typically happens is that
> an entire line of pixels is moved into the row drivers, and then that
> entire row (the equivalent of a CRT "scan line") is written at once.
> This is all under the control of the internal panel electronics, though,
> so you don't have to worry about it in terms of how you drive the
> panel.
>
> Bob M.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

"Chris G" <cgrebeld@hotmail.com> wrote in message
news:74c403e9.0406070607.200523b4@posting.google.com...
> Thanks for the explanations, I have some follow up questions:
>
> I want to determine as precisely as possible, when an image is
> actually displayed on the LCD. If the software is set to 'wait on
> vsync' before it writes into the video buffer, then I should be able
> to predict the time when the image is displayed, if I know what
> scanlines the image is on, when the vsync happened, and the pixel
> response time.

OK, but I would need to know just what you mean by "when
an image is actually displayed on the LCD." Unlike, say,
film projection, in which the entire frame is displayed on the
screen at once when the shutter opens, LCDs are updated one
line at a time. The line of new data is accumulated within
internal buffers in the panel, then written at once into the
appropriate row of pixels - and, within the response time of
that LCD, that new line of image actually becomes visible.
By the time you reach the end of the frame (the last line of
pixels), the entire screen has been written with new data, and
for a very few moments you could say that the entire new
image is visible at once. But as soon as the next frame starts
being written, data from the previous frame will be replaced
by data from the new frame, and clearly for most of the time
the LCD screen is actually showing pieces of two frames at
once. So it's hard to say exactly when "the image is actually
displayed" without knowing the application you intend for
that information.

> Could I do this with the DVI 'display-enable' signal you mention?
> Could you tell me what pin(s) you are talking about?

The "display enable" signal simply means that valid data is
appearing on the interface; you cannot directly use that to
indicate when the new image appears on the screen, as there
is undoubtedly some latency within the monitor itself (up to a
full frame time, depending on the scaling or frame rate
conversion which may be in use). Also, this signal does not
appear on a dedicated pin. In the DVI system, the HSYNC,
VSYNC, display enable, and other control information are
encoded into the same stream that is carrying the video data
itself.

Bob M.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

> LCDs are updated one
> line at a time. The line of new data is accumulated within
> internal buffers in the panel, then written at once into the
> appropriate row of pixels - and, within the response time of
> that LCD, that new line of image actually becomes visible.

The application involves measuring ocular-motor response to visual
stimulation. For example, the LCD screen is black, and then a white
disk is drawn. We want to measure the delay between the disk
appearing on the screen and the brain's response to it.

Since the whole experiment takes like 80ms, I would like to be able to
predict when the target will appear on the screen (say 80% of full
intensity) as accurately as possible. (Within 10 or 15ms)

The software will 'wait-on-vsync' before page-flipping the target
graphic into video memory, so hopefully the first vsync pulse after
the issuance of the page-flip command will be the first frame in which
the target will start appearing on the LCD.

Given that I know:
- the LCD's pixel response time (say 15ms for black->white)
- the refresh rate (60 Hz)
- The 'scan-line' that the target is drawn on

Can I calculate the delay between the first vsync after page_flip()
and when the target will be at 80% intensity?


> By the time you reach the end of the frame (the last line of
> pixels), the entire screen has been written with new data, and
> for a very few moments you could say that the entire new
> image is visible at once. But as soon as the next frame starts
> being written, data from the previous frame will be replaced
> by data from the new frame, and clearly for most of the time
> the LCD screen is actually showing pieces of two frames at
> once. So it's hard to say exactly when "the image is actually
> displayed" without knowing the application you intend for
> that information.

Chris G

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

Chris G wrote:

>> LCDs are updated one
>> line at a time. The line of new data is accumulated within
>> internal buffers in the panel, then written at once into the
>> appropriate row of pixels - and, within the response time of
>> that LCD, that new line of image actually becomes visible.
>
> The application involves measuring ocular-motor response to visual
> stimulation. For example, the LCD screen is black, and then a white
> disk is drawn. We want to measure the delay between the disk
> appearing on the screen and the brain's response to it.
>
> Since the whole experiment takes like 80ms, I would like to be able to
> predict when the target will appear on the screen (say 80% of full
> intensity) as accurately as possible. (Within 10 or 15ms)
>
> The software will 'wait-on-vsync' before page-flipping the target
> graphic into video memory, so hopefully the first vsync pulse after
> the issuance of the page-flip command will be the first frame in which
> the target will start appearing on the LCD.
>
> Given that I know:
> - the LCD's pixel response time (say 15ms for black->white)
> - the refresh rate (60 Hz)
> - The 'scan-line' that the target is drawn on
>
> Can I calculate the delay between the first vsync after page_flip()
> and when the target will be at 80% intensity?
>
>
>> By the time you reach the end of the frame (the last line of
>> pixels), the entire screen has been written with new data, and
>> for a very few moments you could say that the entire new
>> image is visible at once. But as soon as the next frame starts
>> being written, data from the previous frame will be replaced
>> by data from the new frame, and clearly for most of the time
>> the LCD screen is actually showing pieces of two frames at
>> once. So it's hard to say exactly when "the image is actually
>> displayed" without knowing the application you intend for
>> that information.

Rather than trying to calculate you might do better to go after it with a
scope and a light sensitive transistor and measure it.

> Chris G

--
--John
Reply to jclarke at ae tee tee global dot net
(was jclarke at eye bee em dot net)

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

"Chris G" <cgrebeld@hotmail.com> wrote in message
news:74c403e9.0406071738.698b9681@posting.google.com...
> The application involves measuring ocular-motor response to visual
> stimulation. For example, the LCD screen is black, and then a white
> disk is drawn. We want to measure the delay between the disk
> appearing on the screen and the brain's response to it.

OK - but since you're apparently trying to deal with times on the
order of tens of milliseconds at most, I would probably suggest
that there are better ways to do this. A projection system with a
fast shutter, in which the entire image appears at once, would seem
to be far more controllable and preferable. What you're trying
to do COULD certainly be achieved through purely electronic
means, but I believe it will require some rather specialized hardware.


> Can I calculate the delay between the first vsync after page_flip()
> and when the target will be at 80% intensity?

Again, you seem to be assuming that the entire target appears at
once, which is not the case - and becomes much less the case
the larger (greater number of lines in the displayed image) becomes.

Again, please note the following:

> > By the time you reach the end of the frame (the last line of
> > pixels), the entire screen has been written with new data, and
> > for a very few moments you could say that the entire new
> > image is visible at once. But as soon as the next frame starts
> > being written, data from the previous frame will be replaced
> > by data from the new frame, and clearly for most of the time
> > the LCD screen is actually showing pieces of two frames at
> > once. So it's hard to say exactly when "the image is actually
> > displayed" without knowing the application you intend for
> > that information.


Bob M.

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

"Bob Myers" <nospamplease@address.invalid> wrote in message
news:x2rxc.3186$3w.2401@news.cpqcorp.net...
>
> "Chris G" <cgrebeld@hotmail.com> wrote in message
> news:74c403e9.0406071738.698b9681@posting.google.com...
> > The application involves measuring ocular-motor response to visual
> > stimulation. For example, the LCD screen is black, and then a white
> > disk is drawn. We want to measure the delay between the disk
> > appearing on the screen and the brain's response to it.
>
> OK - but since you're apparently trying to deal with times on the
> order of tens of milliseconds at most, I would probably suggest
> that there are better ways to do this. A projection system with a
> fast shutter, in which the entire image appears at once, would seem
> to be far more controllable and preferable. What you're trying
> to do COULD certainly be achieved through purely electronic
> means, but I believe it will require some rather specialized hardware.
>
>
> > Can I calculate the delay between the first vsync after page_flip()
> > and when the target will be at 80% intensity?
>
> Again, you seem to be assuming that the entire target appears at
> once, which is not the case - and becomes much less the case
> the larger (greater number of lines in the displayed image) becomes.
>
> Again, please note the following:
>
> > > By the time you reach the end of the frame (the last line of
> > > pixels), the entire screen has been written with new data, and
> > > for a very few moments you could say that the entire new
> > > image is visible at once. But as soon as the next frame starts
> > > being written, data from the previous frame will be replaced
> > > by data from the new frame, and clearly for most of the time
> > > the LCD screen is actually showing pieces of two frames at
> > > once. So it's hard to say exactly when "the image is actually
> > > displayed" without knowing the application you intend for
> > > that information.
>
>
> Bob M.
>

I agree with Bob - Trying to calibrate such a setup (regardless of using
LCD or CRT as a display) can
be quite a task. Ignoring the display's response issues (both will display
the image as a sequential series
of "line images", the major difference being the actual rise and fall times
of the light output) just trying to
determine (and CONTROL) the actual video card response is a challenge in
itself. Any kind of raster
developed image will be problematic, compared to the human response times
you are seeking, because
they are generally the same order of magnitude.

I heartily suggest some more easily calibrated and controlled type of
imaging system for Human Factors
testing, as Bob suggests.

HTH,

NGA

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

"Not Gimpy Anymore" <nogimpREMOV@msn.com> wrote in message news:<ca5si4$h5k@library2.airnews.net>...
> "Bob Myers" <nospamplease@address.invalid> wrote in message
> news:x2rxc.3186$3w.2401@news.cpqcorp.net...
> >
> > "Chris G" <cgrebeld@hotmail.com> wrote in message
> > news:74c403e9.0406071738.698b9681@posting.google.com...
> > > The application involves measuring ocular-motor response to visual
> > > stimulation. For example, the LCD screen is black, and then a white
> > > disk is drawn. We want to measure the delay between the disk
> > > appearing on the screen and the brain's response to it.
> >
> > OK - but since you're apparently trying to deal with times on the
> > order of tens of milliseconds at most, I would probably suggest
> > that there are better ways to do this. A projection system with a
> > fast shutter, in which the entire image appears at once, would seem
> > to be far more controllable and preferable. What you're trying
> > to do COULD certainly be achieved through purely electronic
> > means, but I believe it will require some rather specialized hardware.
> >
> >
> > > Can I calculate the delay between the first vsync after page_flip()
> > > and when the target will be at 80% intensity?
> >
> > Again, you seem to be assuming that the entire target appears at
> > once, which is not the case - and becomes much less the case
> > the larger (greater number of lines in the displayed image) becomes.
> >
> > Again, please note the following:
> >
> > > > By the time you reach the end of the frame (the last line of
> > > > pixels), the entire screen has been written with new data, and
> > > > for a very few moments you could say that the entire new
> > > > image is visible at once. But as soon as the next frame starts
> > > > being written, data from the previous frame will be replaced
> > > > by data from the new frame, and clearly for most of the time
> > > > the LCD screen is actually showing pieces of two frames at
> > > > once. So it's hard to say exactly when "the image is actually
> > > > displayed" without knowing the application you intend for
> > > > that information.
> >
> >
> > Bob M.
> >
>
> I agree with Bob - Trying to calibrate such a setup (regardless of using
> LCD or CRT as a display) can
> be quite a task. Ignoring the display's response issues (both will display
> the image as a sequential series
> of "line images", the major difference being the actual rise and fall times
> of the light output) just trying to
> determine (and CONTROL) the actual video card response is a challenge in
> itself. Any kind of raster
> developed image will be problematic, compared to the human response times
> you are seeking, because
> they are generally the same order of magnitude.
>
> I heartily suggest some more easily calibrated and controlled type of
> imaging system for Human Factors
> testing, as Bob suggests.
>
> HTH,
>
> NGA



Can you give me an example of a projector that would be appropriate?
From what I've seen there are DLP and LCD projectors, and both of
these appear to have the same problems with synchronization and timing
that a monitor does, but perhaps I've missed something?

What type of projector has a fast shutter, in which the entire image
is displayed at once?

Thanks

 

[Guest]

Archived from groups: comp.sys.ibm.pc.hardware.video (More info?)

"Chris G" <cgrebeld@hotmail.com> wrote in message
news:74c403e9.0406220833.45aa7813@posting.google.com...
> Can you give me an example of a projector that would be appropriate?
> From what I've seen there are DLP and LCD projectors, and both of
> these appear to have the same problems with synchronization and timing
> that a monitor does, but perhaps I've missed something?
>
> What type of projector has a fast shutter, in which the entire image
> is displayed at once?

I think you're still thinking too high-tech; if what you're trying to
do is to measure the response time of subjects to the appearance
of a given image, then why not use a simple slide projector with
an external (i.e., purpose-built) fast shutter between it and the
screen? In other words, DON'T rely on the electronics to change
the image for you - just display a static image, and shutter the
light.

Bob M.