Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Apr 1999 12:55:48 +1000 (EST)
From:      John Birrell <jb@cimlogic.com.au>
To:        aa8vb@ipass.net (Randall Hopper)
Cc:        jb@cimlogic.com.au, multimedia@FreeBSD.ORG
Subject:   Re: Bt848 corruption since upgrading to 3.1. Has DMA code changed?
Message-ID:  <199904130255.MAA04788@cimlogic.com.au>
In-Reply-To: <19990412205545.A3986@ipass.net> from Randall Hopper at "Apr 12, 1999  8:55:45 pm"

next in thread | previous in thread | raw e-mail | index | archive | help
Randall Hopper wrote:
> 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 have SubstructureNotify enabled on the root window, so I see
ConfigureNotify events as any top-level window is moved. I agree that
you don't get a VisibilityNotify event to the TV window when going from
partially obscured to partially obscured, but I don't use that. I have
enough information to work out firstly how much of the TV window is
visible due to clipping by it's own parents (my TV window is scrollable),
and secondly which areas are obscured by top-level windows. The clipping
by the parent windows gives at most 4 clip rectangles, plus one clip
rectangle per top-level window that is above and overlapping. Then if
there are more than 100 clip rectangles, you have to join the ones
that are closest together.

> 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.

In my case, it is only event based. The trick is to try to compress the
number of events that would have you go query the tree. Starting a short
timer and resetting it with each event that hints at the requirement for
a query tree seems to work. As soon as there is one change to the clips
already set, the capture is stopped and restarted when the timer times
out. I'm still playing with the timer value.

>  |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.

I'm not sure what the solution to that is. In my application, I only
allow the TV display when direct video is available because the capture
looks awful using any other mode, and particularly bad if PseudoColor
is the only visual available.

-- 
John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/
CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137


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?199904130255.MAA04788>