In that case, the maintenance risk is actually between:
XDamageCreate(..., XDamageReportBoundingBox);
and
XDamageSubtract().
So to mitigate that risk, we need to ensure:
1. All plugins that use XDamageCreate with BoundingBox need to depend on composite. Already done.
2. Maybe add a comment to composite saying "Don't delete this code!". But the same could be said for lots of critical code.
If you happen to delete the XDamageSubtract code by accident, then I can tell you from experience that you'll know about it because the screen won't update at all. :)
In that case, the maintenance risk is actually between: e(..., XDamageReportBo undingBox) ; act().
XDamageCreat
and
XDamageSubtr
So to mitigate that risk, we need to ensure:
1. All plugins that use XDamageCreate with BoundingBox need to depend on composite. Already done.
2. Maybe add a comment to composite saying "Don't delete this code!". But the same could be said for lots of critical code.
If you happen to delete the XDamageSubtract code by accident, then I can tell you from experience that you'll know about it because the screen won't update at all. :)