"Sottek, Matthew J" wrote: > > >"Sottek, Matthew J" wrote: > >> > >> Here is the proposal again, if there are on complaints I'll > >> implement it this way. > >> > >> #define XV_HOLD 0x0 > >> #define XV_TOP_FIELD 0x1 > >> #define XV_BOTTOM_FIELD 0x2 > >> #define XV_FRAME (XV_TOP_FIELD | XV_BOTTOM_FIELD) > > > >Just to clarify, the default atom value will be XV_FRAME right? > > Yes, existing Xv clients do not need to change anything. It will > works just like it always has. Clients can query for the > XV_FRAME_TYPE atom to see if the driver supports this new > functionality. I plan on resetting it whenever the Overlay is > turned off.
Another question real fast. 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.... 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. Now that I think about it, what effect, if any, will this have on drivers that implement their own multi-buffering? Another clarification question, what happens in this case: XV_FRAME_TYPE = *|XV_HOLD XvShmPutImage() ... XvShmPutImage() ... XvShmPutImage() XV_FRAME_TYPE = *&!XV_HOLD I take it that only the last frame put will show up? --greg. _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
