> Note that this introduces some slight uncertainty in the > display since the overlay might not correspond to the window > location when it comes time to actually display. But that's > not going to be a big deal since the times are short and you > get a delay now anyhow due to the overlay not going into effect > until the retrace on most hardware. It introduces a larger lag > between overlay and image when moving windows which isn't going > to be a big deal.
Right, that delay isn't going to have much of an impact. >You can't do this for blitted video though. The cliplist is stale >by the time you display. Not a problem though since blitted video >are merely fallbacks. Why not? Use two offscreen buffers to hold the data and blit the correct one over when the HOLD bit gets unset. Can't you check the cliplist at the time when the bit is removed? > So, this breaks when we're paused or showing a still and you move > the image around. Ugh. Are you sure this can't be handled in the > hardware without the client having to do another put? Or do you > expect the client to re-put whenever it moves (which it has to > now anyways)? Ok, I slightly modified the idea to take care of this too. I must say, I really really like this one. #define XV_TOP_FIELD 0x01 #define XV_BOTTOM_FIELD 0x02 #define XV_FRAME (XV_TOP_FIELD | XV_BOTTOM_FIELD) #define XV_HOLD 0x04 Mostly the same behavior as before, but now we really use these as bitfields. When the XV_HOLD bit is ON, the data is not updated onscreen at the end of an XvShmPutImage. It has to wait until the HOLD bit is removed. Here is the change, Bits 0 and 1 indicate the fields that will be updated with the next XvShmPutImage. The image position and scaling information are always updated. Here are some example uses. Default Case: (Works just like it does now) XV_FRAME_TYPE = XV_TOP_FIELD | XV_BOTTOM_FIELD (Default) XvShmPutImage: Both fields are updated from the XvImage, the data is updated asap onscreen since the HOLD bit is not on. Interlaced Video: XV_FRAME_TYPE = XV_HOLD | XV_TOP_FIELD | XV_BOTTOM_FIELD XvShmPutImage: The top field and bottom field are updated from the XvImage. The position, size and scaling information are updated from the call, but the overlay is not updated onscreen. XV_FRAME_TYPE = XV_TOP_FIELD The overlay is updated with the latest information and set to show only the top field. The onscreen update happens asap. XV_FRAME_TYPE = XV_BOTTOM_FIELD The overlay is set to show the bottom field and the onscreen update happens asap. Paused Video: Loop: XV_FRAME_TYPE = XV_HOLD XvShmPutImage: NO Fields are updated from the XvImage, but the position and scaling information are taken from the call. The overlay is not updated onscreen. XV_FRAME_TYPE = XV_TOP_FIELD On Screen changed happen asap. goto Loop Paused Video (Better way): Loop: XV_FRAME_TYPE = 0x0 XvShmPutImage: NO Fields are updated from the XvImage, the position and scaling information are updated. The HOLD bit is not set so overlay is updated asap. This means that for a pause you just set The frame type to 0 and continue with puts as normal. No data copying takes place. goto Loop Field at a Time Interlaced: XV_FRAME_TYPE = XV_HOLD | XV_TOP_FIELD XvShmPutImage: Only the top field is read from the XvImage. This is done by taking the first line and then skipping every other line. The position, size and scaling are updated from the call. XV_FRAME_TYPE = XV_TOP_FIELD Update on screen happens asap. XV_FRAME_TYPE = XV_HOLD | XV_BOTTOM_FIELD XvShmPutImage: Only the bottom field is read from the XvImage. Position, size and scaling are updated but not onscreen. XV_FRAME_TYPE = XV_BOTTOM_FIELD Onscreen update happens asap. Repeat. -Matt _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
