Re: Getting event's time

New Message Reply Date view Thread view Subject view Author view

Angus Dorbie (dorbie++at++multipass)
Mon, 24 Nov 1997 11:54:57 -0800


On Nov 24, 8:14pm, Salvador Bayarri. Univ. Valencia wrote:
> Subject: Getting event's time
>
> [ plain text
> Encoded with "quoted-printable" ] :

>
> Hi, Performer world.
>
> My point is the following one. I would like to get accurate timing
> information about user events, especially about key strokes, and also
> about the precise moment where the user can start seeing a new frame,
> that is, the time when the new frame is actually presented in the
> display.
>
> In the first case, the device events, I wonder if there is in
> the GL or X system any function to directly check the state of the device,
> like there was the 'Boolean getbutton(device)' function in IRIS GL.
> In that case I could perform a periodic checking with the desired
> time accuracy.
> Otherwise, is there any timing information associated to events in
> OpenGL or X events that can be retrieved?
>
> Concerning the new visible frame timing, I'm aware that the new frame
> becomes visible at one of the video updates, but I don't see any easy way
> to know exactly which of them and associate time information to it.
>
> Any information or reference would be appreciated for ever...
>

On the subject of the video update of interest you need to be able
to guarantee you can render the scene content within a given time
period. If you take longer then your data will be older than you had
anticipated.

You can use pfFrameRate to limit the swapbuffers to an interval
longer than the vertical retrace which you know you can draw in
time. So if you can't always draw in 16.7 ms then you could set a
frame rate of 30 Hz and draw everything inside 33.3 ms, if you
take less than 16.7 it won't swap so you can rely on computing
the scene content for 33.3 ms hence plus MP latency determined
by the process model.

Predictive load management is notoriously difficult. Performer
provides a mechanism of load management for geometry and pixel
fill which uses previous rendering times to stress the levels of
detail and apply DVR to help ensure that frame rate is met. In this
way you limit what is drawn by dynamically reducing the scene
complexity and allowing you to meet a target frame rate say 60 Hz.
As rendering time approaches 16.7ms then stress level increases
and the scene complexity reduces to leave some breathing space,
when performance increases stress reduces to increase complexity
and draw more detail again without exceeding the hard 16.7 ms.
This method relies on extrapolating from earlier frame times, using
enough margin for error to make things work. It is not predictive.

Cheers,Angus.
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:56:15 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.