Re: DRAW process blocks?

New Message Reply Date view Thread view Subject view Author view

John Rohlf (jrohlf++at++tubes)
Wed, 13 Mar 96 11:25:09 PST


>
> Hi there,
>
> I'm a little puzzled about the behavior of the DRAW process. According to the
> stats, when DRAW is forked as a separate process, it doesn't begin processing
> until the next frame boundary. As a result, I'm seeing a two frame latency in
> PFMP_APPCULL_DRAW mode.
>
>
> -----> a0 (sync) ||-| || ||
> || |--| c0 || ||
> || (draw blocks) ||----------| d0 || (swap)
>
> In PFMP_APP_CULLDRAW, 1 frame latency.
>
> -----> a0 (sync) ||-| ||
> || |--| c0 ||
> || |----------| d0 || (swap)
>
> In Prog. Guide, it states that both of these modes should only have 1 frame
> latency. Why does the DRAW block until the next frame boundary? Does it do so
> in cases other than being a separate process? Thanks!
>
>
> --
> gene koh gene++at++corp.sgi.com 415.933.4230
>
> simplicity patience compassion
>
>

        This is kind of a squirrelly situation which has come up before.
I'd say the documentation is incorrect - PFMP_APPCULL_DRAW does give
2 frame latency. However, there are 2 ways to get 1 frame latency with
PFMP_APPCULL_DRAW:

        1. Perform *all* application processing between
        pfSync() and pfFrame().

        2. Use PFMP_CULLoDRAW.

(1) should give you better throughput.


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:52:33 PDT

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