> From: Mark Vojkovich <[EMAIL PROTECTED]> > Date: Wed, 31 Jul 2002 12:42:10 -0700 (PDT) > > On Wed, 31 Jul 2002, Steve Kirkendall wrote: > > > The testxv.c program has an XFlush(display) call, but it's commented > > out. Because of this, the XShmPutImage(...) requests are all queued > > until Xlib's request queue fills up, at which time they are all sent > > in one big chunk. This could make the "frames per second" value > > fluctuate wildly, giving meaningless results. It wouldn't look very > > good on the screen, either. But try replacing the commented-out > > XFlush(...) call with the above code, first. > > XGetGeometry will flush. > > > > > Also, testxv.c calls XGetGeometry() inside the loop. I believe > > this is a round-trip request (can somebody confirm that?) which > > would slow down the display loop. You'd be better off watching > > for ConfigureNotify events. > > Actually XGetGeometry would work as an XSync(). This would > have the same effect as flushing and getting the notify event, plus > it gets geometry changes. It's probably more efficient overall than > flushing and waiting for Completion or ConfigureNotify events. > > Mark.
Let me try paraphrasing that, to see if I've got it right. The XGetGeometry() call will serve multiple roles: It will flush the request queue; it will wait for completion of the XvShmPutImage() request (because the X server always completes *ALL* pending requests before sending a response to a round trip request?); it will get the window's current geometry. Consequently, the only change needed in testxv.c is, the last parameter of the XvShmPutImage() call should be changed from True to False so the X server won't send completion events. That will prevent the client's event queue from growing endlessly, which is what the original poster was concerned about. Is that right? _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
