On Thu, 2001-11-22 at 10:42, Peter Surda wrote: > On Wed, Nov 21, 2001 at 11:50:57AM -0800, Mark Vojkovich wrote: > > This is an application bug. Apps are supposed to Grab the > > port when they want to use it so noone else can. When an app > > tries to grab the port and finds that it is already grabbed > > it will know that it is in use and it should fall back to some > > other method to display the video. When the apps do not grab > > the port they are using, continual preempting of each other's > > video is the expected behavior. > Hmm, does it really have to be like this? From my understanding of how > XvShmPutImage is implemented on most cards, there should be a way to implement > this reasonably: > > - make sure when allocating offscreen memory for data that it doesn't overlap > - make sure when *CopyData422/420 are using DMA that only 1 DMA transfer > happens at a time (dunno, is this really necessary?) > - make sure calling *DisplayVideo422/420 only happens once at a time (from my > experience this takes an insignificant amount of time => chance that these 2 > will overlap is low => can be ignored > > So, in theory, making sure the allocated memory segments don't overlap should > be enough. As the CopyData422/420 takes almost all the time of the PutImage > function, there shouldn't be any strage slowdown besides lineary proportional > to the amount of data transferred (i.e. image size*depth). > > Or am I missing something here (as usually <g>)?
Yes, only one image can be displayed at a time per port so why bother. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
