Created attachment 4037 [details]
The test program

Created attachment 4324 [details] [review]
no-damage-for-CRM-on-MoveWindow-1.patch

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.

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.

Created attachment 4336 [details] [review]
no-damage-for-CRM-on-MoveWindow-3.patch

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
damageInMoveWindow
- 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.

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.

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

*** Bug 1788 has been marked as a duplicate of this bug. ***

Would be nice if this could finally be fixed for 7.4.

(Compiz was fixed not to rely on this behaviour a while ago)

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_.

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)

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

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

-- 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.