On Fri, 2016-04-29 at 16:09 +0200, Erlend Langseth wrote: > The first problem is that nothing appears in the window when I > comment out line 41. I'm unsure how it normally works, but I suppose > that when I do compositing, then I want the windows to be entierly > off screen, so I don't want to `XMapWindow` them. Please correct me > if I'm wrong.
I must correct you, you are wrong. Unmapped windows have no pixel storage even with compositing enabled. A manually redirected window effectively does have "entirely off-screen" storage though. > Another problem is that once I try to listen for Damage events, it > only happens once, in the start. Generally I only want to know when > damage happens, not which parts are damaged etc. What did I miss > here? Yep, that's how it works. Registering for damage on a drawable triggers an initial damage event for the whole drawable [1]. It's then your responsibility to tell the X server that you've processed that event by using XDamageSubtract. In your particular case, you're asking for ReportNonEmpty, so you want to say XDamageSubtract(dpy, damage, None, None) to report that you've handled all the damage for the drawable. Once you've done that the server will generate new events when new damage happens, and you'll need to subtract it back off again each time. > And a final question: Looking at xcompmgr source code, it uses > 'Regions' from the Xfixes extension, such as XFixesCreateRegion etc. > Will I need that in my quest to do simple compositing without > consideration to exactly which area is damaged? No. Using XDamageSubtract as above is sufficient to clear drawable damage away without building regions. > So my quest is to assemble the bare essentials of compositing several > ARGB windows onto one window. I have probably skipped something > essential, but I do find it quite hard to find out exactly what I > need to do (have any general tips on how to get around the poor > documentation of some parts of Xlib?). For many of the "modern" extensions like Damage or Present, the best documentation is simply the protocol specification, as the library interface is a straightforward mapping onto the protocol, and often the spec describes the rationale and expected usage. For Damage, for example: https://cgit.freedesktop.org/xorg/proto/damageproto/tree/damageproto.txt The missing man pages are pretty lame; we'd happily take patches. [1] - Practically speaking, this is to provide a natural way for compositors to start processing damage events, rather than needing an artificial "pretend the whole surface is damaged" step on the first iteration. - ajax _______________________________________________ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
