Bug 361674

Created attachment 98364 [details]
damage monitoring utility

damage notifications ain't the wm's job, but ftr: that would imply that if you activate kwin compositing, the desktop likely won't update anymore either (but only the panel?)

otherwise the bug is rather on your end

it's the opposite, everything works fine with compositing enabled. Any hint on which component I should be looking at given it's not the WM? I have tried a bunch of other desktop environments with the same version of X and I'm only seeing this in KDE.

the bug is already reassigned to plasmashell.

ftr, this isn't necessarily a bug at all: an exposure will cause a repaint, But that doesn't imply requirement for a damage event. in doubt nothing updated in the desktop window.

however: you do get damage events when you (not so much) expose the desktop in a composited setup??

it looks like with compositing enabled any change causes a damage event for the whole screen, which is the same behaviour as KDE4.

From the desktop window? You can expect one from the compositor overlay (ie. where it paints everything) since there are visual updates for every minor change of course.


What exactly are you trying to do?

from the root window (which I guess is the same as the desktop window?). 

I'm trying to accumulate damaged regions so that I can scrape only pixels that have changed, then encode and transmit them over the network to remote the desktop.

(In reply to mcottrell from comment #7)
> from the root window (which I guess is the same as the desktop window?).

Nope. the plasmashell desktop containment is a regular root child (top level window) with special tags to be known as "desktop" - you'll however get every event on the root window if you listen to child events (didn't check your code)

> I'm trying to accumulate damaged regions so that I can scrape only pixels
> that have changed, then encode and transmit them over the network to remote
> the desktop.

Just listen to exposure events in addition - you should not get them while a compositor does the screen and even iff, they'll be part of the damage events from the compositor scene anyway.

(In reply to Thomas Lübking from comment #8)
> (In reply to mcottrell from comment #7)
> > from the root window (which I guess is the same as the desktop window?).
> 
> Nope. the plasmashell desktop containment is a regular root child (top level
> window) with special tags to be known as "desktop" - you'll however get
> every event on the root window if you listen to child events (didn't check
> your code)

by listen to child events do you mean setting the event mask for every child window? I tried with xlib and xcb and haven't had any luck finding a way to do this in any other way, but I could be missing something blindingly obvious...

> 
> > I'm trying to accumulate damaged regions so that I can scrape only pixels
> > that have changed, then encode and transmit them over the network to remote
> > the desktop.
> 
> Just listen to exposure events in addition - you should not get them while a
> compositor does the screen and even iff, they'll be part of the damage
> events from the compositor scene anyway.

I ran "xwininfo -tree -root" and tried all of the windows that cover the whole desktop (i.e. window size is 1920x1200):

     0x3600019 (has no name): ()  1920x1200+0+0  +0+0
        1 child:
        0x360001a (has no name): ()  1920x1200+0+0  +0+0
           1 child:
           0x3400013 "Desktop — Plasma": ("plasmashell" "plasmashell")  1920x1200+0+0  +0+0

but when running xev on those windows looking at expose events, I'm seeing nothing when I minimise either a full screen window or a window obscuring part of the desktop. Is the "Desktop — Plasma" window the one you were referring to as the one tagged to be known as "desktop"?

thanks for your replies so far.

The X11 server is "unfortunately" pretty much free in deciding when to create expose events (it does so, because it has no data for the window), this could be defeated by a cache (backing store) or bypassing overlay output (not uncommon for GLX)

There's afaik no method to get all frontbuffer updates from the server.
VNC keeps a copy of the framebuffer and compares the pixels of n with n-1 to know which regions to update.

Combining Damage and Un/Map and ConfigureNotify events (alongside a Z test for the latter two) might get you a complete idea on the flattened update region... :-(

(In reply to Thomas Lübking from comment #10)
> The X11 server is "unfortunately" pretty much free in deciding when to
> create expose events (it does so, because it has no data for the window),
> this could be defeated by a cache (backing store) or bypassing overlay
> output (not uncommon for GLX)
> 
> There's afaik no method to get all frontbuffer updates from the server.
> VNC keeps a copy of the framebuffer and compares the pixels of n with n-1 to
> know which regions to update.
> 
> Combining Damage and Un/Map and ConfigureNotify events (alongside a Z test
> for the latter two) might get you a complete idea on the flattened update
> region... :-(

I have code to do the n to n-1 comparison, I was using damage events as it seemed like it would be more efficient. Unfortunately it also seems like a less reliable way to keep track of all change. I have stopped using damage events as from what you have said there is no way to guarantee that that they will show all change on a display, and when compositing is active they don't provide much useful information anyway.

I'm not sure what you want to do with this bug. If you feel it's not actually a bug as the desktop is not required to emit damage events when it is exposed (because as you say, it's likely it hasn't actually changed behind the window covering it), then go ahead and close it. I opened it as it was a difference in behaviour from what I have seen in KDE4 and various other desktop environments.

I don't maintain plasmashell.
If it's a bug, it's likely upstream (and driven by the GL overlay window nature)