Quoting Joachim Breitner :

Am Mittwoch, den 05.10.2011, 12:04 +0200 schrieb Bastien Dejean:

...

I noticed that my wallpaper (or the root window if there is none) is appearing briefly (i.e. flashing) during client creation / destruction in tiled layouts.

This jerky effect is not happening in Fullscreen layout.

just confirming this effect; here it also happens when switching between workspaces, independent of the Fullscreen layout. Not having this flickering would indeed be nice.

Some work has been done since the last release to mitigate this effect. Have you tried the latest code from darcs yet? ~d

wagnerdm@seas.upenn.edu [2011.10.05 0925 -0400]:

Quoting Joachim Breitner :

...

Am Mittwoch, den 05.10.2011, 12:04 +0200 schrieb Bastien Dejean:

...

I noticed that my wallpaper (or the root window if there is none) is appearing briefly (i.e. flashing) during client creation / destruction in tiled layouts.

This jerky effect is not happening in Fullscreen layout.

just confirming this effect; here it also happens when switching between workspaces, independent of the Fullscreen layout. Not having this flickering would indeed be nice.

Some work has been done since the last release to mitigate this effect. Have you tried the latest code from darcs yet?

Well, "mitigate" is the right word here and it certainly is much less noticeable. Nevertheless, there is still some flicker in window creation/destruction. I would suspect that this is simply in the nature of X: to eliminate any flicker with window creation/destruction would require a transaction model that asks the X server to redraw the entire screen only once all windows have been repositioned, treating the manipulation of multiple top-level windows as a single transaction. As far as I understand it, that's simply not part of the X protocol. Cheers, Norbert

Bastien Dejean [2011.10.05 2055 +0200]:

Norbert Zeh a écrit :

...

I would suspect that this is simply in the nature of X: to eliminate any flicker with window creation/destruction would require a transaction model that asks the X server to redraw the entire screen only once all windows have been repositioned, treating the manipulation of multiple top-level windows as a single transaction. As far as I understand it, that's simply not part of the X protocol.

Is that situation improved with XCB?

I'm no expert on this at all, and I know nearly nothing about XCB. So I cannot really answer this question. Having said this (and having started a long explanation of why I think that the situation with XCB should not be any different than with the standard Xlib), I just realized that the reasoning in my original message is flawed. My reasoning was that visually manipulating multiple top-level windows is hard if not impossible to do in a flicker-free manner simply because the X server is not designed to treat the manipulation of multiple such windows as one atomic change. I do think that this is true (even though I'd be happy to learn that I'm wrong). If I am right, the interface used to interact with the server (Xlib or XCB) should not make any difference. However, if you consider how DEs with more focus on eye candy handle desktop switches with or without fancy effects, there is usually no flicker involved, but the basic operation is the same: sets of windows are mapped/unmapped and/or change their positions. So there must be a way to work around this limitation of the X server, if it even is a limitation that does not only exist in my head. I have no idea how hard this would be to implement. Cheers, Norbert -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

wagnerdm@seas.upenn.edu writes:

That strategy doesn't work when the layout of all the windows changes, since a window cannot be mapped at two places (and, potentially, sizes!) at once.

You could dump the contents of the workspace region to a pixmap, render that pixmap to a new (unmanaged) window covering the entire workspace, perform window movement/mapping behind it and unmap the covering window at the end. This would work, but it's ugly and complex. I doubt a simple and robust solution to this aesthetic issue can be conceived. -- \ Troels /\ Henriksen

wagnerdm@seas.upenn.edu [2011.10.06 1017 -0400]:

Quoting Troels Henriksen :

...

wagnerdm@seas.upenn.edu writes:

...

That strategy doesn't work when the layout of all the windows changes, since a window cannot be mapped at two places (and, potentially, sizes!) at once.

You could dump the contents of the workspace region to a pixmap, render that pixmap to a new (unmanaged) window covering the entire workspace, perform window movement/mapping behind it and unmap the covering window at the end. This would work, but it's ugly and complex. I doubt a simple and robust solution to this aesthetic issue can be conceived.

Cute. The generalization of this idea leads directly to a simple, robust solution: never unmap clients, and using OpenGL compositing to hide them instead. ;-)

Compositing is pretty much what I was thinking about when I was mentioning other DEs. I was thinking about a scenario where I'm switching to a different desktop using fancy effects (e.g., a slide motion). In that case, the switch is not a simple matter of mapping one set of windows and then unmapping the previous set of windows. I agree with Troels, though, that a simple and robust solution may be impossible, and I certainly value these two attributes of xmonad more highly than a bit of flicker upon layout changes. Cheers, Norbert