>If I blt a frame with the XV_FRAME_TYPE atom set to XV_FRAME|XV_HOLD, >and then, sometime later, I set the atom to XV_FRAME, what kind of >latency would I be looking at before that held buffer would show up? >Is setting atoms a synchronous call? Would I be certain the frame is >on the screen when it returns? I don't really care which way as >long as....
I will flip the buffer on the the next vertical retrace. The XvSetAtom call will return quickly as long as you don't call it more than once per vertical retrace, then is has to block. >Can it be required that all XV_HOLD --> !XV_HOLD transitions happen >in the vblank somewhere? That way I can just worry about setting the >atom as close to frame display time as I can and not worry about the >tearing. I guess I am just looking for another way to work around not >getting vsyncs at my level. It would be nice, I'm not sure all hardware can do this. >Now that I think about it, what effect, if any, will this have on >drivers that implement their own multi-buffering? It shouldn't have any impact. We use double buffers on i810. This just allow for two things. #1 You can do TOP_FIELD BOTTOM_FIELD which was not possible before. and #2 There is no longer an unknown time between when you ask for a flip and the actual flip, or rather the unknown time is very much shorter since the data copy has been separated from the display request. Internal to the driver things are a little more difficult to understand. My overlay has a buffer#1 and buffer#2 but those pointers are not necessarily pointing to surface#1 and surface#2. Like in XvMC I may have 6 or 7 surfaces and I just point the unused overlay buffer pointer to the next surface I want to display. This is the same thing with just 2 surfaces. >Another clarification question, what happens in this case: >XV_FRAME_TYPE = *|XV_HOLD >XvShmPutImage() >... >XvShmPutImage() >... >XvShmPutImage() >XV_FRAME_TYPE = *&!XV_HOLD Note: You are a little confused. We are not going with the complicated proposal with the bitfields. It was just too hard and the reputImage() function should get me what I was trying to achieve. XV_FRAME_TYPE can only be 0-3 XV_HOLD,XV_TOP_FIELD,XV_BOTTOM_FIELD,XV_FRAME. SO your question should go like this: XV_FRAME_TYPE = XV_HOLD XvShmPutImage() ... XvShmPutImage() ... XvShmPutImage() XV_FRAME_TYPE = XV_FRAME The target of the XvShmPutImage will only change when XV_HOLD is set. (Or if XvShmPutImage is called without XV_HOLD) So however many XvShmPutImage()'s get called while in XV_HOLD get put in the same place overwriting each other. Once I get an implementation done I'll write up some clear documentation. -Matt _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
