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 _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
