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