From: Mark V. <MVo...@nv...> - 2002-06-27 19:38:31
|
On Thu, 27 Jun 2002, H}kan Hjort wrote: > > > We only send a new frame every 1/24, 1/25 or 1/29 of a second i.e. > > > some where between every 35-42 milliseconds. This was with a refresh > > > rate of 76 / 85 Hz. So there should never have been more than the > > > current overlay and one image in the queue. These where GeForce4 cards. > > > (and yes we wait for the shm completion event before modifying the > > > xvimage again) > > > > You can never guarantee that. The X-server might not have even > > been scheduled when you made those request. Even at 1/24 the > > X-server might wake up to find that it has 3 frames in its > > queue. Linux and it's coarse scheduling are not well suited for > > multimedia. The server is definitely in the position where > > it has more frames to process than the hardware can queue. > > I hope you didn't mean 3 frames in it's in queue, as in that it hasn't > been scheduled to run for (3*42) 126ms. That is 12! scheduler ticks > and I find that very hard to belive. The X server does not consume > all that much cpu time, hence has a rather high priority. Maybe Ogle is making a mistake someplace. I don't know very much about Linux scheduling, but if you have 2 or 3 threads pounding away at the CPU, how often does the X-server really get CPU time? Also, (and this is a topic I have discussed with knowledgeable kernel people) just because the client sends something to the X-server doesn't mean the X-server is going to get run to process it. The X-server is in select() waiting for activity on its file descriptors. I'm told that, depending on how much time is left in its last allotment, it may not get run until after the next time the slices are computed, even though it has data ready to be processed. I'm wondering if lowering the server's nice level would have an effect. > > I'll see if I can get my friend to try changing HZ to 1000 (1024) and > testing again. > > > That's the only time this kind of thing can happen. I can > > get rid of the backwards moving artifact with a more careful > > choice of which buffer I overwrite, but you'll still get a > > shear when this happens unless I spin until the next free > > buffer. > > > That would certanly improve things, but one imagines that DOUBLE_BUFFER > should imply that one would get no shear/trearing. I can only ensure that if I spin and wait for a buffer to be freed. Mark. |