On Sat, 2008-08-16 at 19:19 -0700, Nathaniel Smith wrote: > There hasn't been any activity on this bug after 6 months, so I > thought I'd send a note to the list asking for advice on how to get it > fixed... > > The full description of the problem is here: > https://bugs.freedesktop.org/show_bug.cgi?id=14648 > but basically, the issue is that Damage has this "clever" code -- I > guess intended to help make things async-safe, but as far as I can > tell, any code that would be helped is already irreparably broken -- > that makes it impossible to write efficient screen-monitoring programs > (think like x11vnc or screencast recorders). You have to forgo > Damage's ability to compress out redundant damage events (meaning that > if something is drawing quickly to a particular region, you get a > storm of events saying that the same area is damaged over and over), > because if you *do* try to use it, then Damage ends up sending O(n^2) > redundant damage events when processing complex damage regions (where > n is the number of distinct modified rectangles within the window, and > can get very large when you are monitoring an app that is clever and > tries to minimize the total number of pixels it draws on).
I've just read through the bug and discussion of this, and I had a couple of comments. It seems to me that there are a couple of simple techniques that you could take to reduce problems in your application. (Maybe you've already tried some of these) First, instead of calling XSubtractDamage on each rectangle individually in the region you've accumulated client-side, you could instead build an XFixesRegion with *all* of the rectangles in the accumulated damage region, and XSubtractDamage that. At that point, the only areas that will be re-reported are those that are "in flight" ... that the server has sent but you haven't yet processed. (You can even ignore the "in flight" rectangles by examining event serial numbers. Any damage events with serial numbers less than that of your last XSubtractDamage() call can be ignored. See XNextRequest() for how to get the serial number of a particular request. Still just adding them to your region twice should be almost as cheap.) Second, you could just offload the acculation of damage completely to the server. When you decide that it's time to send new data over the wire: - Call XSubtractRegion() with repair=None - Retrieve the resulting 'parts' region and use that to decide what region of the image to retrieve and send over the wire. This is an extra round-trip to the X server, but its not going to matter in the big scheme of things. The usefulness of re-reporting the left-over damage is certainly not obvious to me. I can make up ways of using the damage extension that would rely on it, but they aren't the ways I would normally expect people to do things. Without having full replay to the contents of Keith's head when the spec was being written, we'll probably never know for certain why its there. I don't think it can just be struck out of the spec, however. Even if nobody relies on it, the damage extension has been widely deployed and used, and making incompatible changes to semantics would go against reasonable maintenance policies. Another level also doesn't make sense to me, since re-reporting of left-over damage is really completely orthogonal from level.. it occurs at all levels. If my above suggestions aren't enough to resolve the problem, I think a fix would probably adding another option to the Damage object for that. That might be exposed as a DamageChangeAttributes along the lines of RenderChangePicture or ChangeWindowAttributes. Or could simply be a simple "setter" request. - Owen _______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
