Composite ClipNotify fix and expose event elimination
ville.syrjala at nokia.com
Tue Dec 21 13:22:20 PST 2010
On Mon, Dec 20, 2010 at 10:34:34AM -0800, ext Keith Packard wrote:
> On Mon, 20 Dec 2010 20:30:34 +0200, Ville Syrjälä <ville.syrjala at nokia.com> wrote:
> > Yeah. I'm not 100% sold on that myself yet. miValidateTree & co. don't
> > seem to sink in without some conscious effort.
> As you might imagine, clipping bugs are really nasty to fix.
> > 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`
> Thanks. I'd love to see this cleaned up and automated so that we can
> verify that it works. I'd suggest having it run against a server that
> isn't running a window manager or compositing manager so that it doesn't
> fight those.
> You could also have it run entirely within another window to avoid
> interactions with the window manager, but that wouldn't test the root
> case (which is often special).
I cooked up some kind of small tool that could do some automated tests.
Basically you just tell it what window manipulation operation you want
to do, and what areas you expect to be exposed. It then compares the
expected areas with the actual expose events. And you can also tell it
to read the window content with XGetImage and compare the results with
the expected value.
Someone more clever could have probably written it in two or three lines
of python, or whatever the language of the day is, but I did in C. I
hijacked a copy of the the region code from the X server to help me
sort out the exposed areas.
The example script I included passes without complaints with a server
that my patches applied. An unpatched server naturally generates quite
a few unnecessary exposes.
More information about the xorg-devel