> I wasn't expecting clients to call XV_HOLD then Put and not >display it afterwards. There seem to be two feasible implemenations: > >1) XV_HOLD stays into effect until it is displayed. If a second > Put comes along before the display the new Put overrides the > first. > >2) XV_HOLD gets canceled after a second put. I expect 1) is easier > to implement.
The cleanest concept is to have the client set the XV_FRAME_TYPE and not let the driver alter it. The client is then in total control of the display. The only way the overlay will change after having been set to XV_HOLD is for the client to set it to something else. So this isn't really what you describe in #1. The XV_HOLD stays in effect until the client changes it. XV_FRAME_TYPE modifies the behavior of XvShmPutImage() but XvShmPutImage() does not have an effect on XV_FRAME_TYPE. Let's describe it this way. When XV_FRAME_TYPE is XV_HOLD all changes to the overlay are held in a buffer until the XV_HOLD state is removed. This includes all atoms, data, position and scaling parameters. Only the latest values will be used when the XV_HOLD state is exited. Further, the overlay will only display the requested fields when displaying. When XV_FRAME_TYPE is not XV_HOLD all changes to data, position, scaling, and atoms are applied as soon as possible. The overlay will only display the requested fields when displaying. This is actually really useful. Then you can change a bunch of attributes and the data during a XV_HOLD. The changes will all show up at the same time when you remove the XV_HOLD. As it is now changing an attribute requires an overlay update which may make your next flip have to wait. That is undesirable. -Matt _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
