Drawing to a window's backing store is reported as damage against the obscuring window, not the window actually drawn upon. For example, given a window heirarchy as follows... Parent and Child_1 (same size): ------------------------------ | | | Child_2: Child_1a: | | ---------- ---------- | | | | | | | | | | | | | | | | | | | | | | | | | | ---------- ---------- | | | ------------------------------ Parent: @(0,0) for [30,11] Child_1: @(0,0) for [30,11], BackingStore=WhenMapped Child_2 (a sibling of Child_1): @(3,3) for [10,6] Child_1a (an inferior of Child_1): @(17,3) for [10,6] ... create and map the windows; create DAMAGE level=RawRectangles for Child_1, Child_2, and Child_1a; create a GC with SubwindowMode=ClipByChildren; then draw a zero-width line drawn on Child_1 from (0,5) through (29,5). Expected result: DamageNotify on Child_1 @(0,5) for [30,1] Actual result: DamageNotify on Child_2 @(0,2) for [10,1] DamageNotify on Child_1a @(0,2) for [10,1] DamageNotify on Child_1 @(0,5) for [3,1] DamageNotify on Child_1 @(13,5) for [17,1] The damage reported on child_1a and child_2 is unexpected because the drawing has not affected either of these windows. Tested on X.Org servers version 6.8.2 (Damage v1.0) and 1.3.0 (Damage v1.1). Possibly related to bug 3785, but probably not.
do you mean /xorg/xorg-server-1.9.y/damageext/damageext.c ? that code is tiny (compared to X's GC's and redraw/active X widget for redraw callback code) it is not meant to be a widget callback to notify applications exactly what and when X needs a widget redrawn, nor a query tool of, nor directly used as it appears to me to be a mechanism by which a querying application can get notification of possible hits: not to be used as actual hits ------------------- i havent' read all the docs on it, but just a quick look tells me that .c is nothing like what you are thinking it's for
This bug was not written with any particular source code in view, but from an X client (functional) perspective. The point of the bug is that the Damage extension is acting inefficiently in that it is creating events (and likely causing re-painting) for windows that are actually unaffected by a drawing operation. > DamageNotify on Child_2 @(0,2) for [10,1] Child_2 is a non-inferior and the drawing operation occurs in backing store for Child_1. This event is unnecessary because the visible contents of Child_2 are unchanged. > DamageNotify on Child_1a @(0,2) for [10,1] Child_1a is an inferior window, and technically, backing store is not maintained behind it. So no pixels in this region are affected, even in backing store, by the drawing operation. This event is unnecessary, again because the visible contents of Child_1a are unaffected. > DamageNotify on Child_1 @(0,5) for [3,1] > DamageNotify on Child_1 @(13,5) for [17,1] While these events cover the visible pixels on Child_1 affected by the drawing operation, they are inconsistent with the Damage specification ("A reasonable goal is for each primitive object drawn (line, string, rectangle) to be represented as a single rectangle") -- or conversely, they are not specific enough as the second segment includes Child_1a space in which no backing store exists and no pixels were altered. The expected event is a single rectangle for the line drawing operation, which is reported only against window Child_1 since only it's contents actually need to be redrawn. Whether you care to improve the Damage extension eventing is up to you, I'm just letting you know it could be improved. It may well involve changes to code outside of the Damage extension itself.
-- 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/364.
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.