From owner-freebsd-multimedia Tue Apr 21 16:14:14 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA17736 for freebsd-multimedia-outgoing; Tue, 21 Apr 1998 16:14:14 -0700 (PDT) (envelope-from owner-freebsd-multimedia@FreeBSD.ORG) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA17706; Tue, 21 Apr 1998 23:13:52 GMT (envelope-from rhh@ct.picker.com) Received: from ct.picker.com by whqvax.picker.com with SMTP; Tue, 21 Apr 1998 19:12:46 -0400 (EDT) Received: from elmer.ct.picker.com by ct.picker.com (4.1/SMI-4.1) id AA13507; Tue, 21 Apr 98 19:12:45 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id TAA21827; Tue, 21 Apr 1998 19:11:58 -0400 Message-Id: <19980421191158.A21774@ct.picker.com> Date: Tue, 21 Apr 1998 19:11:58 -0400 From: Randall Hopper To: Luigi Rizzo 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 Mail-Followup-To: Luigi Rizzo , hasty@rah.star-gate.com, sos@FreeBSD.ORG, jerry@freeside.fc.net, multimedia@FreeBSD.ORG References: <19980420062633.B9931@ct.picker.com> <199804201152.NAA14216@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199804201152.NAA14216@labinfo.iet.unipi.it>; from Luigi Rizzo on Mon, Apr 20, 1998 at 01:52:13PM +0200 Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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