XDamage extension over-reports window damage

[Joel Dice]

I'm usually just a lurker on this list, but this is a topic that I have 
some experience with, since I have designed and implemented the 
application-sharing component of my organization's conferencing product.

On Thu, 27 Jan 2005, Jonathan Lennox wrote:

> On Wednesday, January 26 2005, "Keith Packard" wrote to "Jonathan Lennox, xorg at lists.freedesktop.org, Keith Packard" saying:
>>
>> Around 15 o'clock on Jan 26, Jonathan Lennox wrote:
>>
>>> Specifically, I've noticed two problems.  First of all, Xdamage reports
>>> damage if a window *obscured* by the one I'm monitoring is drawn to.  E.g.,
>>> if I have output going to an XTerm that is partially obscured by the window
>>> I'm monitoring, the area of my window that covers the XTerm continually gets
>>> damage reports.
>>
>> I think this can probably be fixed; the limitation here is that damage
>> monitoring occurs only on the target holdin the physical pixels; when two
>> windows share the same physical target (e.g. the screen), then damage
>> monitoring on one will see damage done to the other; the trick is to clip
>> the damage so that it doesn't impact the underlying window.
>>
>> It can't be fixed in all cases; the damage inside the server is reported
>> in rectangular units, so some (odd) drawing will still "leak" through to
>> the underlying window.
>
> Can't you just clip the damage region to the window visible region, for
> windows without backing store?  I've not been able to figure out enough
> about X server internals to determine what structure describes the window
> visible region, but the X server must have this information in order to draw
> to the screen.
>
> (On a related note, I'd love to be able as a client to retrieve and track
> changes to the window visible region, so I know for what parts of the window
> XGetImage is meaningful.  I can semi-track things with XVisibilityEvent and
> XExposureEvent, but that doesn't suffice for the visibility region
> shrinking.  The former part seems like a natural fit for Xfixes?)

What I do to address this is track the position of every window on the 
screen at all times and compute the visible regions myself.  It would be 
nice if the server could do this for us, but it's not necessary.

What I haven't figured out is how to reliably determine which application 
a arbitrary window belongs to.  This is easy enough on MS Windows - you 
can translate a any window ID into a process ID and from there determine 
the executable path and canonical application name.  The best I've been 
able to do under X11 is group windows together based on XmuClientWindow() 
and the WM_CLIENT_LEADER atom, but this doesn't always work - menus often 
have no obvious relationship to their parent frames.

>
>>> In this case, with raw or delta damage report types, it seems like
>>> damage reports should be sent just for the area of fvwm2's trim, but instead
>>> I get a rectangle encompassing the entire window.
>>
>> Again, damage is internally recorded in rectangular units, so an operation
>> which ends up reporting only a single large rectangle can appear to damage
>> the internal window contents.
>>
>> The guarantee Damage provides is that you will get notification whenever
>> the contents of the window changes; it doesn't guarantee that you will get
>> minimal notification.  Changes to the server which reduce overreporting
>> would be gratefully accepted.
>
> Do you have any suggestions as to what's the best way to determine what's
> causing the overreporting?  Will Xdamage and Xrecord timestamps correspond
> for events triggered by the same client requests?
>
> To motivate all of this, I'm trying to implement an X-based server for the
> protocol defined in the Internet-Draft
> <http://www.ietf.org/internet-drafts/draft-lennox-avt-app-sharing-00.txt>.
> It's like VNC, but optionally window-based, so you can share individual
> applications -- e.g., just a slideshow, as part of a multimedia conference
> -- instead of your whole desktop.

I look forward to reading this.  It's about time we had a standard 
protocol for this kind of thing.

>
> -- 
> Jonathan Lennox
> lennox at cs.columbia.edu
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg