Date: Mon, 12 Apr 1999 18:58:09 -0400 From: Randall Hopper <aa8vb@ipass.net> To: John Birrell <jb@cimlogic.com.au> Cc: mbendiks@eunet.no, multimedia@FreeBSD.ORG Subject: Re: Bt848 corruption since upgrading to 3.1. Has DMA code changed? Message-ID: <19990412185809.A1176@ipass.net> In-Reply-To: <199904120808.SAA02011@cimlogic.com.au>; from John Birrell on Mon, Apr 12, 1999 at 06:08:17PM %2B1000 References: <199904120535.HAA05298@labinfo.iet.unipi.it> <199904120808.SAA02011@cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
John Birrell: |Luigi Rizzo wrote: |> > Also, the display freezes whenever I move a window over, but I'd assume |> > that's standard behaviour. |> |> this is because fxtv switches from direct video access to using X11 |> calls, and this causes a huge overload on the system (for moving |> video data). |> in this respect fxtv should be a bit more adaptive -- when switching to |> use X11 it should really work one or two frames at a time and try to |> synchronize with the server. | |fxtv doesn't use the clipping features provided by the bktr driver/hardware. |When a ConfigureNotify event is received, fxtv stops are restarts the |conversion. With the window partially obscured, fxtv won't use direct |video. It should track the windows above in the sibling stack and |set the clip array. This would allow the hardware to continue to use dma. As it turns out, this has all come up and been discussed before. Due to the absense of progressive occlusion events and the asynchronous nature of X, this isn't practical. Rather than re-evolve all this, here are a few -multimedia snippets circa 4/20/98. Randall Randall Hopper: |Luigi Rizzo: | |Amancio Hasty: | |> This is a flaw in the current X server protocol model. It can tell you | |> what happened now what is about to happened . | | ^^^ i assume this is "not" | | | |you mean that you know that a window is occluded but don't know what | |parts of the window are visible and what not ? (or it would be a lot of | |work to scan through all windows and determine the shape of the visible | |area, duplicating the work already done by the server ?) | |Exactly. There are two design issues that make it impractical from an X app |standpoint. | |First (as you mentioned), there isn't a decent event-driven way to keep an |exposed region definition up-to-date with X (polling the X server's |complete window list every 10th of a second doesn't qualify :-); it isn't |practical and wouldn't work solve it completely anyway). | |Second, X dispatching to clients is asynchronous so by the time you get the |heretofore unknown "here's-your-exposed-region-definition" event, that |region definition has already changed, and starting capture with that |region definition may stomp an occluded window. | |Likely a similar issue exists with MSWin as the Hauppauge software forces a |refresh of the entire screen just about everytime anything window-event |related happens anywhere on the screen, on the off-chance something got |stomped by the direct framebuffer writes. | |As far as purely technical issues for using clipping, back when I worked |with Amancio's clipping in Oct 97, there were a few bugs related to the |clipping. But these are easily solvable and Amancio may have fixed them |since then: ... Randall Hopper: |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 Randall Hopper: |Luigi Rizzo: | |> This is a flaw in the current X server protocol model. It can tell you | |> what happened now what is about to happened . | | ^^^ i assume this is "not" | | | |you mean that you know that a window is occluded but don't know what | |parts of the window are visible and what not ? | |Yes, that's an issue, but more importantly you don't get an event when |your window is Partially Occluded and another piece of the then-visable |area is occluded. You only get events when window occlusion (who's |covering me) changes between: Totally Unoccluded, Partially Occluded, |Completely Occluded. | |Short of polling the window list rapidly, there's no way to stay up-to-date. | |Then there's the asynchronous nature of X, but I described a bit about that |in a msg last night. 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?19990412185809.A1176>