Composite ClipNotify fix and expose event elimination
ville.syrjala at nokia.com
Mon Dec 20 10:30:34 PST 2010
On Mon, Dec 20, 2010 at 10:05:42AM -0800, ext Keith Packard wrote:
> On Mon, 20 Dec 2010 18:05:38 +0200, ville.syrjala at nokia.com wrote:
> > Rather than continue my attempts to hack around the issue of incorrect
> > ClipNotifys during window redirection changes, I decided to tackle the
> > issue in more proper manner.
> > This series will remove the internal MapWindow+UnmapWindow cycle and
> > replace it with a single ValidateTree+HandleExposures pass through
> > the affected windows.
> Thanks! As you might imagine, the whole unmap/map adventure was a short
> cut to ensure that all of the regions ended up recomputed correctly:
> * compRedirectWindow
> + Redirected window has anything formerly obscured now exposed
> + Underlying windows are exposed where the redirected window was
> * compFreeClientWindow
> + Un-Redirected window gets painted from backing pixmap
> + Underlying window clip lists get updated
> Do you have any small test cases that verify that these are working for
> both manual and automatic redirect in each direction? I'm concerned that
> the validation code won't 'just work' in all cases...
Yeah. I'm not 100% sold on that myself yet. miValidateTree & co. don't
seem to sink in without some conscious effort.
I've attached an ugly test app I was using. Just ignore/rip out the xv
stuff etc. You can run it, for example, like so:
'xvredirect -F -d -s -b 10`
You can input 'm'/'a'/'u' for manual/automatic/unredirected redirection
for the middle sibling. 'M'/'A'/'U' to do the same for the top level
window. It will print the expose events it receives.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 15675 bytes
Desc: not available
More information about the xorg-devel