Re: Swapbuffer control problems in multipipe mode

New Message Reply Date view Thread view Subject view Author view

John Rohlf (jrohlf++at++tubes)
Fri, 8 Sep 95 18:42:39 PDT


>
> Hello!
>
> As Michael T. Jones had already confirmed, there is a bug concerning
> the swapbuffer control in PF1.2; it consists in that, when the DRAW
> process gets ready within 1/60 sec, the buffer swaps at the next
> vertical retrace period, even if pfFrameRate is set to 30 and pfPhase
> is PFPHASE_LOCK.
>
> While running our application in single pipe mode, we had our own
> swap control function (declared in pfPipeSwapFunc), which forced the
> DRAW process (from the second frame on) to wait until the next frame
> boundary:
>
> void SwapPipe (pfPipe *pipe)
> {
> static double t1=0, t2=0;
> t2 = pfGetTime ();
> while ((t2-t1) < 1/30.) t2 = pfGetTime ();
> t1 = t2;
> swapbuffers();
> }
>
> Currently we are changing our application from single pipe
> to multipipe mode and we found out that our workaround does not
> work any more. The same effect occurs also when using PFPHASE_FLOAT
> or PFPHASE_LIMIT and of course if we don't use any workaround.

        This should work in multipipe if you are genlocked which
is an absolute requirement for proper operation. Another option is the
following:

        while (((pfGetVClock() - startV) % fieldsPerFrame))
                                != fieldsPerFrame - 2)
        {
                sginap(1);
        }

where startV is the vclock value when drawing begins. If you are using
LOCK you may be able to omit the - startV.


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

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