Date: Mon, 12 Apr 1999 20:55:45 -0400 From: Randall Hopper <aa8vb@ipass.net> To: John Birrell <jb@cimlogic.com.au> Cc: multimedia@FreeBSD.ORG Subject: Re: Bt848 corruption since upgrading to 3.1. Has DMA code changed? Message-ID: <19990412205545.A3986@ipass.net> In-Reply-To: <199904122337.JAA04421@cimlogic.com.au>; from John Birrell on Tue, Apr 13, 1999 at 09:37:01AM %2B1000 References: <19990412185809.A1176@ipass.net> <199904122337.JAA04421@cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990412205545.A3986>