[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-xorg-devel
Subject:    Re: [PATCH xserver] composite: Inhibit window background paint with
From:       Ville =?iso-8859-1?Q?Syrj=E4l=E4?= <syrjala () sci ! fi>
Date:       2011-07-29 12:23:43
Message-ID: 20110729122343.GA2832 () sci ! fi
[Download RAW message or body]

On Sat, Jul 23, 2011 at 04:00:11PM +0300, Ville Syrjälä wrote:
> On Fri, Jul 22, 2011 at 02:49:54PM -0400, Owen Taylor wrote:
> > On Thu, 2011-07-21 at 00:24 +0300, Ville Syrjälä wrote:
> > > > I did actually have to see it live to figure out what was going on ...
> > > > but once I saw it, and thought about it a bit, I was able to avoid
> > > > digging out the debugger.
> > > > 
> > > > What's going on is that for a window with a non-None background, the
> > > > copying between the parent pixmap and the composite pixmap that we do
> > > > isn't sufficient - all that copying is doing is making sure that things
> > > > _look_ right initially - it doesn't actually suppress expose event
> > > > generation and the background painting that happens during expose event
> > > > generation.
> > > 
> > > The pointless expose events were supposed to be eliminated by another
> > > patch set [1]. At least my test app [2] manages to redirect/unredirect
> > > non-None windows w/o generating unnecessary expose events.
> > 
> > Hmm, OK, I had those patches applied, but figured that the expose events
> > were being generated by some other path than Map/Unmap. It turns out
> > that they were being generated because my test Mutter code wasn't
> > ordering things correctly.
> > 
> > With that fixed, I can't reproduce any flickering with Evince. It
> > redirects and unredirects seamlessly when I pop up a menu. (This is with
> > GTK+-3, but there shouldn't be any difference from GTK+-2 in this
> > regard.)
> > 
> > So, I'm not sure what was happening in your testing but I'm pretty happy
> > with how things are working for me!
> 
> I suppose it's possible compiz does things in the wrong order as well. I
> never bothered to investigate the issue properly since compiz and GTK+
> weren't my real target with these patches.

I had a quick look at compiz and indeed the problem was a simple
ordering issue. I sent patches [1] to fix it.

[1] http://lists.compiz.org/pipermail/dev/2011-July/001465.html

-- 
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

[prev in list] [next in list] [prev in thread] [next in thread]