Bug 5275 - Moving a window generates damage events
Summary: Moving a window generates damage events
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: high normal
Assignee: Adam Jackson
QA Contact: Xorg Project Team
: 1788 (view as bug list)
Depends on:
Reported: 2005-12-08 07:43 UTC by Søren Sandmann Pedersen
Modified: 2018-12-13 22:16 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:

The test program (1.71 KB, text/plain)
2005-12-08 07:46 UTC, Søren Sandmann Pedersen
no flags Details
no-damage-for-CRM-on-MoveWindow-1.patch (4.17 KB, patch)
2006-01-11 10:48 UTC, Adam Jackson
no flags Details | Splinter Review
no-damage-for-CRM-on-MoveWindow-3.patch (6.80 KB, patch)
2006-01-13 10:19 UTC, Adam Jackson
no flags Details | Splinter Review

Description Søren Sandmann Pedersen 2005-12-08 07:43:55 UTC
Just moving a window around causes damage events to be sent to the window 
even though no pixels change in it. This happens regardless of whether the
window is redirected or not. See test program.

You could argue that this bug is a special case of a more general "The semantics
of the damage extension is entirely unclear".
Comment 1 Søren Sandmann Pedersen 2005-12-08 07:46:19 UTC
Created attachment 4037 [details]
The test program
Comment 2 Adam Jackson 2006-01-11 10:48:32 UTC
Created attachment 4324 [details] [review]

probable fix (totally untested).  wrap the DamageCreate in damageext, mark when
we're inside MoveWindow, and silence external Damage reports for
CompositeRedirectManual windows when in MoveWindow.

ugly little layering violation here but it ought to work, at least for windows
created after the compmgr is activated.  the only other option i see is to
somehow wrap ->MarkOverlappedWindows to never mark CRM windows, but i imagine
that having undesirable effects elsewhere.
Comment 3 Adam Jackson 2006-01-11 11:22:37 UTC
after a moment's reflection, perhaps a better idea is to just expose a new
function from the composite core:

int compWindowRedirectionMode(WindowPtr pWin);

that basically just returns cw->update, or zero if not redirected and cw is
NULL.  then have Damage (internal or protocol sides, not sure which) take care
of silencing the damage request.
Comment 4 Adam Jackson 2006-01-13 10:19:14 UTC
Created attachment 4336 [details] [review]

slightly less terrible:

- add compRedirectMode, which returns the redirection mode for a window (even
if implicit)
- wrap ->MoveWindow in the damage core and expose that through
- check for both in DamageExtReport

the MoveWindow wrap is unpleasant, style-wise, but it does work.  the test app
does still catch some Damage events but they're not generated from the
MoveWindow path.

this is still kinda contentious, it might break rendering for compmgrs that
don't watch for normal window move events.  i don't know if any such compmgrs
exist though.
Comment 5 Michel Dänzer 2007-02-12 03:28:30 UTC
What's the status of this? AFAICT some distros have been using some variant of this for a while, but OTOH at least compiz is relying on window moves generating damage. Would be nice if this could be resolved once and for all.
Comment 6 Daniel Stone 2007-02-27 01:29:15 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 7 Michel Dänzer 2008-02-26 02:13:30 UTC
*** Bug 1788 has been marked as a duplicate of this bug. ***
Comment 8 Michel Dänzer 2008-02-26 02:16:58 UTC
Would be nice if this could finally be fixed for 7.4.

(Compiz was fixed not to rely on this behaviour a while ago)
Comment 9 Adam Jackson 2008-05-06 10:11:26 UTC
I really don't like applying this for 1.5.  Changing the Damage semantics isn't really a good thing until we have some idea of what we want them to _be_.
Comment 10 debguy 2014-11-28 05:25:05 UTC
probable fix (totally untested).  wrap the DamageCreate in damageext


do not tell me Xorg causes redraw updates when not needed and a hack using some new foreign extention should be implemented, thats total bull XFree86 doesn't

you KNOW the minute you base code on some hacked extention they'll reversion and your program will no longer compile without yet more extensive changes and reliance on their "new extention"

do it the right way. RTFM (read the manual)
Comment 11 debguy 2014-11-28 05:34:08 UTC
this is a good time to remember that your program and client should be "separate programs". 

responding to events may or may never happened depeneds on server (which might forget it or be down or not support temporarily)

recursive requests by server are made (requests that come in while request fuction activated by X is in the middle of it's codee running - causing client program to crash if it didn't know that was ossible)

your graphics handlers should all be re-entrant and handle the whole widget tree of requests (it's difficult, so use GTK or something don't go low level if you don't need do)

your PROGRAM should be separate (X client forked from).  it should handle talking to to to the fork that's being harassed by X but not be tied to X itself.  ie, it could know if user input is hung up and be able to shut down without X callign a function for it to do so.  it should be autonomous.

X client and server can never say what the other can do it's impossible to know if it will happen until it does (hardware error?  user killed ? ...)

many try to implement cloud filesystems that have problems with disk corruption and etc

PROBLEM?  same.  there are spin locks (thread lock).  two disperate servers can never know the full state of the other's locks and whether before they are spun if they will be spun. any software which thinks it knows: is a program that will have synch issues and corruption
Comment 12 debguy 2014-11-28 05:37:34 UTC
see: Open Desktop Administrator's Guide

for the real rundown chart of the client programs , X and input/displays , server , all fit together in a system of internet (or local) connected apps that are not supposed to rely on knowing for sure what the other may do.  they may only ask, check, and follow up to see if it was done.  they may assume it was and if so, should offer some way for an application running that is not only triggered by X to handle things, ie, maybe through xrdb, rough example
Comment 13 GitLab Migration User 2018-12-13 22:16:07 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/337.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.