From owner-freebsd-multimedia Mon Apr 12 17:58:22 1999 Delivered-To: freebsd-multimedia@freebsd.org Received: from pluto.ipass.net (pluto.ipass.net [198.79.53.5]) by hub.freebsd.org (Postfix) with ESMTP id 2EB8714CFD for ; Mon, 12 Apr 1999 17:58:02 -0700 (PDT) (envelope-from rhh@ipass.net) Received: from stealth.ipass.net. (ts6-200-ppp.ipass.net [198.78.59.200]) by pluto.ipass.net (8.9.1a/8.9.1) with ESMTP id UAA17682; Mon, 12 Apr 1999 20:55:36 -0400 (EDT) Received: (from rhh@localhost) by stealth.ipass.net. (8.9.1/8.8.8) id UAA05500; Mon, 12 Apr 1999 20:55:45 -0400 (EDT) (envelope-from rhh) Date: Mon, 12 Apr 1999 20:55:45 -0400 From: Randall Hopper To: John Birrell Cc: multimedia@FreeBSD.ORG Subject: Re: Bt848 corruption since upgrading to 3.1. Has DMA code changed? Message-ID: <19990412205545.A3986@ipass.net> References: <19990412185809.A1176@ipass.net> <199904122337.JAA04421@cimlogic.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199904122337.JAA04421@cimlogic.com.au>; from John Birrell on Tue, Apr 13, 1999 at 09:37:01AM +1000 Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org John Birrell: |If fxtv can handle the popping up of the file menu and handle the |transition from direct video to XImage updates (which involves restarting |the capture) without the dma clobbering the file menu, then it can be |made to handle clipping IMHO. The premise here is the kicker we can't guarentee because the X server makes no claims toward synronicity or even event delivery order, both of which are required to avoid DMA stomping on occlusion. So forced exposes remain our best bet there (since DGA exclusive mode is out of of the question). |I tried keeping an up-to-date child-of-root-window stack by just |processing events from the root window. There seems to be some missing |event information around the time when the window manager re-parents |the top level window. Interesting. |Since direct video requires a local X server, I found that querying the |window tree (when the application sees an event which possibly affects |stacking or occlusion) is quick enough to work out the clip array and |restart the video capture with that. The "when the application sees and event which possibly affects stacking or occlusion" is the real kicker. When moving from partial obscuration to partial obscuration, the app may not get anything in some cases. For example, when sliding a window across another window you get some tell-tale exposes, but consider this case: ------- ------- | A | | A | | |---- | |---- ------- TV | ===> ------- TV | | |---- | ------- ------- | ----| | | B | | B | ------- ------- We start with the left image. The TV window is partially obscured. We end up partially obscured. No event for that. And we're more obscured than before, so we don't even get any tell-tale expose events to give us a clue. I'm currently sided against polling the stacking order. If we don't get an event for all cases, kicking us to go check the stacking order, we shouldn't go eating CPU polling it all the time. |The forced refresh by mapping and unmapping a window over the top still |seems to be required because I can't find a way of getting the capture to |stop before the X server copies the area to the relocated window. Yeah, that's the asynchronous any-order event delivery. |FWIW, fxtv renders X unusable on my system in full PAL size when I |pop up the file menu and the application changes to XImage mode. If |I halve the size, then I can actually get to the quit button. Ouch. Glad you mentioned that. We should do something to help with this. I'll put it on the list for after finals next month. Randall To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message