Race condition in XDamage
Owen Taylor
otaylor at redhat.com
Thu Feb 3 17:54:05 PST 2005
On Thu, 2005-02-03 at 14:57 -0500, Jonathan Lennox wrote:
> In some of my experimentation with the damage extension, I've discovered
> what appears to be a race condition in the extension definition.
>
> If a damage report level other than DamageReportRawRectangles is chosen,
> it's possible for a client which is monitoring the contents of a window to
> miss a change to the window. Here's the flow of events.
>
> ("Client" is drawing to a window; "Monitor" is receiving DamageNotify events
> with level == DamageReportDeltaRectangles and using XGetImage to update its
> private pixmap of the window.)
>
> * Monitor's damage region is empty.
> * Client draws to a region R of the window.
> * The server sends DamageNotify events to Monitor reporting damages to
> region R. Monitor's damage region now == R.
> * Monitor calls XGetImage on region R.
> * Client draws again within region R. Since the drawing is contained within
> Monitor's existing damage region, no DamageNotify events are sent.
> * Monitor calls DamageSubtract on R.
>
> Monitor's copy of the window is now missing Client's second update! I've
> actually observed this happening.
>
> The potential solutions, as far as I can tell, are either to a) always use
> raw reports, or b) for Monitor to grab the server before XGetImage and
> release it after DamageSubtract. Is there some other alternative I'm
> missing?
Why not just reverse the calls to DamageSubtract and XGetImage? That's
the normal thing to do. You might do a little extra work if someone
draws again in-between but that's harmless.
Regards,
Owen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20050203/27af502b/attachment.pgp>
More information about the xorg
mailing list