Hi, Here is a proof-of-concept rough cut at an extension to track "damage regions" for the screen (notify clients about pixels that have changed).
Been thinking about this for a while in order to support desktop pagers with thumbnailing, but was finally inspired to write code by the "krfb" client-side VNC implementation http://www.tjansen.de/krfb/, a very useful application that right now has to poll pixels in a timeout. (http://xf4vnc.sourceforge.net/ is another possible approach for that specific app.) Aside from VNC the extension is useful for desktop pagers, magnifiers, whatever. All the screenshot hacks we're currently using due to Keith not finishing cool fast ways to do this stuff. ;-) The current code is very rough (debug printf's left in there, xedit commented out because I couldn't make it build, I didn't finish the Xrender bits in midamage.c, etc.) but does basically work for me. Code at http://people.redhat.com/~hp/xdamage.tar.gz for now, I'll append the README. Would appreciate any comments people have. As will be obvious from reading the code I'm pretty clueless about X server hacking. Havoc README The "DAMAGE" extension is an extension to track a damage region for the screen. i.e. each time a pixel on the screen changes, it's considered "damage" and reported to interested clients. This extension is intended to make screenshot hacks more viable. "Screenshot hacks" include a variety of applications such as screen magnifiers, screen thumbnailers (e.g. window manager pagers), and client-side VNC implementations. Without the damage extension, these applications have to poll the screen contents in a timeout, which typically uses too much CPU to be practical. The damage extension will probably become obsolete when the server has built-in facilities for syncing the contents of one window to another window or a shared image, including optional scaling prior to sync. Then a magnifier or thumbnailer simply sets up such an autosync relationship and displays the sync target. Interface === The damage extension is very simple; for each screen that supports damage reporting, a client can create any number of "DamageRecorder" resources. A DamageRecorder tracks a damage region for the screen. Each time the screen changes, the damaged area is added to the damage region. At any time the client can ask the DamageRecorder for the current damage region, or a sub-area of it. When the damage region is returned, it is also reset. The region is returned and reset in one step to avoid the obvious race condition. Each active DamageRecorder generates DamageNotify events when the damage region is updated. Interface Open Questions === 1) Should there be a single atomic operation to not only get and reset the damage region, but also GetImage the damage region? I don't *think* this is required for semantic correctness, though perhaps it eliminates an extra round trip. It looks annoying to implement though especially if shared images are optionally used. 2) What exactly are the semantics of DamageNotify events? Are they sent: a) whenever the damage region goes from empty to non-empty b) whenever the damage region changes c) whenever the bounding box of the damage region changes d) whenever the damage region changes, but with some (client-configurable?) rate limit e) whenever the damage region region changes by some (client-configurable?) area increment? Currently the implementation does b), but this creates a *lot* of events. Implementation === The implementation is a straight ripoff of misprite.c, as suggested by Keith Packard. It simply updates all damage regions when the screen changes, instead of hiding the sprite. But uses the same wrap-the-screen-and-gc-funcs code. To add support for the extension, drivers call miDamageInitialize() which wraps their screen functions. Right now I've only added miDamageInitialize() to the xnest driver. The wrappers check whether there are any active DamageRecorder objects before they do any real computation, so the overhead when not actively using the extension should be minimal. Implementation Open Questions === 1) Each driver should report whether it supports the extension, as some screens of a display can support it while others do not. Where/how should this be marked? In a devPrivate field on each screen? 2) Does it work? Need some way to comprehensively test midamage.c, need to check client/server with different byte order, etc. _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
