Date: Tue, 21 Apr 1998 19:11:58 -0400 From: Randall Hopper <rhh@ct.picker.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: hasty@rah.star-gate.com, sos@FreeBSD.ORG, jerry@freeside.fc.net, multimedia@FreeBSD.ORG Subject: Re: problem capturing video with BT848/Haughpage Win/Tv Message-ID: <19980421191158.A21774@ct.picker.com> In-Reply-To: <199804201152.NAA14216@labinfo.iet.unipi.it>; from Luigi Rizzo on Mon, Apr 20, 1998 at 01:52:13PM %2B0200 References: <19980420062633.B9931@ct.picker.com> <199804201152.NAA14216@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Luigi Rizzo: |> Second, X dispatching to clients is asynchronous so by the time you get the |> heretofore unknown "here's-your-exposed-region-definition" event, that | |but i don't understand, the same problem should occur when the whole |window is visible and at some point it is obscured by some other |window: you still have a race condition, right ? Right, this is still an issue. Example: TV window is unoccluded (on top). User pushes the TV window behind another window. Milliseconds later, X tells us this happened, but by this time we've scribbled all over the occluding window with direct video. The occluding window may have already updated itself. Other examples: moving the window around the screen. |How do you solve it ? Well, there isn't a works-always solution without locking the X server in exclusive mode (the way DGA was intended to be used). But this is too limiting. Who wants a TV app where you have to chose between direct video and being able to mess with other clients simultanously. So what Fxtv does is just run in non-exclusive mode and force an expose on the region of the display occupied by the TV window whenever we stop capturing in direct video mode. This forces surrounding windows (the root window, other clients that might have gotten popped on top and stomped, etc.) to update themselves whenever we move the TV window or the TV window changes between on-top and underneath-something. This works pretty well. But it isn't guarenteed to work for everything. If while direct video is on, an X client is grabbing bits off the frame buffer (e.g. snapshotting a window, or doing fast bitblt scrolling, etc.), it can end up propagating this video trash to other areas of the screen or to pixmaps in memory where the forced-expose doesn't clean it up. I haven't seen leftover TV trash anywhere in months. This is more likely to be an issue for folks with slower systems. Randall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980421191158.A21774>