[PATCH xserver] composite: Inhibit window background paint with manual subwindow redirection

Owen Taylor otaylor at redhat.com
Wed Jul 20 14:06:24 PDT 2011


On Wed, 2011-07-20 at 10:44 -0400, Owen Taylor wrote:
> On Wed, 2011-07-20 at 02:54 +0300, Ville Syrjälä wrote:
> 
> > BTW I noticed afterwards that this doesn't help all apps. Evince, for
> > example, still blinks whenever I bring up the popup menu while in
> > fullscreen mode, whereas Firefox doesn't blink. I did some quick
> > protocol tracing and I saw some window background mode changes from
> > the client. A quick look at gdk-x11 code revealed that it does some
> > tricks with the window background. I never got around to testing if
> > removing that code would make Evince blink-free (tm).
> 
> Interesting... there are certainly tricks being played there, but it's
> hard to see why they would cause blinking.
[...]
> The only thing I can think of is that evince might be changing it's size
> when popping up the menu, but that seems pretty strange. Hard to guess
> at without a live situation to debug.

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.

Fixing this - looks hard! I couldn't immediately see a way of doing it
without modifying ScreenRec, and I couldn't immediately see what
modifications to ScreenRec would make sense. I suppose the easiest, if
hacky thing would be to have some way of removing computed expose
areas between pScreen->ValidateTree and pScreen->HandleExposures.

(Or slight variant - having some way to completely suppress exposure
generation during a sequence of ValidateTree/HandleExposures and only
worry about the case where *no* exposures area necessary.)

- Owen




More information about the xorg-devel mailing list