Re: Stats Question correction
Angus Dorbie (dorbie++at++sgi.com)
Mon, 06 Apr 1998 19:41:08 -0700
Marcus Barnes wrote:
>
> On Apr 6, 1:42pm, Angus Dorbie wrote:
> >Marcus Barnes wrote:
> >>
> >> I don't believe that this timeline takes the video refresh period into
> >> account.
> >> Recall that the draw is double buffered. Therefore you don't actually see
> the
> >> results of the draw process for another "video frame". This adds to your
> >> latency.
> >
> >This is incorrect.
>
> [chuckle]
>
> >The vertical line is the vertical retrace. When the
> >draw ends it swaps and the image is switched at the next vertical
> >retrace, in the diagram this is the line at the end of draw. Almost
> immediately
> >thereafter the video starts getting sent on the wire without any video
> >buffering and should begin to appear on your screen if you use CRTs.
>
> Raster refresh takes a full video field (interlaced) or frame (noninterlaced).
> The scan out is a sequential operation after all. On a 60Hz noninterlaced
> monitor (most common these days) that means an additional 16.67 ms. of latency
> before the man in the loop sees the update caused by his sitck input.
>
> >There are different schools of thought on where latency should be
> >measured to. Some say the beginning of video, others say the end
> >but it has little to do with the I.G. You say potato I say potato.
>
> Latency includes the period of time between a control input and the resulting
> feedback. In this case, feedback means a visable update of the display. You can
> choose to ignore video refesh, and input sampling latency for that matter, when
> calculating your end to end latency ... if it like. Just keep some motion
> sickness bags handy ;)
This whole thing boils down to where you compute latency to, the
end of vertical retrace or the beginning. Different RFPs have different
statements about this. The simple fact is that on a CRT you begin to
see the new image almost immediately and a field later all is visible.
You can actually perceive the difference on displays where multiple
channels are vertically abutted unless you reverse the scan direction.
You say tomato I say tomato.
Cheers,Angus.
--
"Only the mediocre are always at their best." -- Jean Giraudoux
For advanced 3D graphics Performer + OpenGL based examples and tutors:
http://www.dorbie.com/
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2
on Mon Aug 10 1998 - 17:57:13 PDT