use damage to track any lost screen changes

[jsorg71]

fix for #171

[matt335672]

This looks clean to me, but I can't pretend to know enough about an X server to comment on the functionality.

@Nexarian - are there any implications on #183 from this? Do we need to merge this one and then re-test yours do you think?

[Nexarian]

First, I think some further documentation as to how xorgxrdp works is in order here, as I'll concede I also don't fully understand everything here. What is damage and why is it a bug that we need to enable it at all? Is this going to cause any performance degradation?

I will do some testing this week to double-check that this doesn't interfere with the screen resizing patch. However, based on my knowledge of how this works, I don't think this will be a problem. The fix I created is strictly related to direct interactions with the memory buffer. If, in the memory buffer's case, a bad update from damage detection comes in during a resize, well, that's the same issue as the rdpCapture timer firing with a bad update, and exactly what my fix is designed to prevent in the first place.

In fact, it may actually improve resizing. Sometimes there are graphical glitches on resize that "go away" once you start manipulating the screen. The biggest glitch often has to do with the desktop's background looking weird, though that's more of a problem with Mate versus Gnome 3, and I didn't consider it a big of enough deal to investigate.

[Nexarian]

My reply was a bit fuzzy on action items, here's what I would expect to close this out:

1. Create another backlog item that captures this concern: xorgxrdp race to paint window #171 (comment) -- So that we can resolve the original user request. That way, we can track debugging why Damage is necessary without blocking them.

1.5: Modify the PR to link to this issue as a //TODO:

2. Add some documentation as to what Damage is and why this patch is necessary and what makes it a bug in the first place. This can either be done with (1) or side-by-side in the code, I care not which.

3. I will test that this does not materially impact my changes that I've made to resize. If it does impact it, I propose that we still go forward with this patch as it addresses an actual user need, whereas resize isn't live in XRDP yet, and then I'll work with you all to figure out how to move forward. This is not blocking and the patch could go forward without my testing if push came to shove.

I should be able to get that testing done by the end of this week at the absolute latest, and I think the documentation piece should be straightforward, so we're very close to wrapping this up.

[Nexarian]

Tested this with https://github.com/Nexarian/xorgxrdp/tree/resize_damage_enhancement -- It works. I wonder if it will impact performance, however. Still, better to fix the bug.

[jsorg71]

Let's wait on this one till we're done with resize. This one is small and easy to rebase.

[Nexarian]

@jsorg71 The thing that's now blocking resize is that we're not sure how to fix the integration with NeutrinoRDP. I've looked at it, and it doesn't look easy. I'm not sure if FreeRDP 1.0.1 on which NeutrinoRDP is based supported the dynamic monitor channel.

If that's the case, we need to update to FreeRDP 2.0 to make it work or have some way to disable the resize functionality elegantly with NeutrinoRDP.

[trishume]

Why the 10ms timer here? Is this repeating or just a hack around something not being initialized yet, which could break if 10ms isn't long enough. Maybe add a comment?

[jsorg71]

I think they are initialized just after the current call. The 10 can be anything bigger then 0. If I remember right, 0 does nothing. Let me see if there is another way to register these things at the right point.

[saddy001]

Fixes neutrinolabs/xrdp#1964

[Nexarian]

@jsorg71 I see no reason to not merge this in anymore. I think I understand what's going on. Normally all of the calls to the Xorg backend are wrapped by the xorgxrdp driver. However, in spite of all the drawing primitive APIs being wrapped for our own customized damage detection, some changes are not being reported through that mechanism.

This uses the X damage routine which lets X tell us when things have changed, and sometimes we need that in spite of our custom wrapping.

That's annoying, but it doesn't sound like a performance hit. If you still think we need this, I'm good to go with it. @matt335672 @metalefty

[matt335672]

@Nexarian - see recent comments on #171.

After your recent work on this, are you still happy to merge this?

[Nexarian]

Yes, go ahead.