Hi Ryan, Now that you point out what the cause of the issue is, it makes sense. I had to add cursor blending support for a customer requirement to correctly handle multiple users connected at the same time on the same session. RDP has no message to notify multiple connected clients of cursor movements, as cursor movements are driven by the client, not the other way around. This means that even if the cursor image itself can be remoted, the server cannot tell the client to draw it at a specific position. I intended to make the cursor blending versus cursor remoting better, by simply activating cursor blending in the case where more than one user are connected, or when the server detects that the cursor was moved to a position that does not correspond to the client's reported position. Please keep in mind that the shadow server is still a work in progress, even if it is vastly superior already to its predecessors (xfreerdp-server, wfreerdp-server, mfreerdp-server).
Best regards, -Marc-Andre On Thu, Oct 30, 2014 at 9:59 PM, Ryan Bair <ryandb...@gmail.com> wrote: > The regions under the mouse cursor are being updated at full blast. I > believe the issue is in x11_shadow_blend_cursor, disabling it drastically > reduces bandwidth usage. I'm suspecting the cursor is being added to the > image and then compared against the next frame which does not have the > cursor triggering an update. I haven't looked too closely as I'm hoping to > replace that functionality with client side pointer. > > It looks like a lot of the machinery for sending the pointer updates to > the client are already in place, but just not wired up. All in all, it > doesn't look too terrible. > > My real world C background is limited so forgive me if I'm off base with > this, but I'm not in love with the shadow_client_thread event loop. I > believe I'll need to add a `pointerEvent` handle to the > rdp_shadow_subsystem struct and events list (given to > WaitForMultipleObjects), another `if` to check the handle, and a pointer > to the new pointer data so I can send it the appropriate message to the > client. I'm imagining that if the list of handles grows as more features as > added (sound, clipboard, etc) that the struct and loop will get pretty > scary. > > Is my general procedure correct? > > Could this loop be improved with something like libuv's inter-thread > communication facilities? > > On Sat, Oct 25, 2014 at 10:45 AM, Marc-André Moreau < > marcandre.mor...@gmail.com> wrote: > >> Hi Ryan, >> >> In certain cases xdamage can return useful information, but to be 100% >> certain we would still need to use it as a hint and perform comparison on >> the next and previous frame to detect regions that have truly changed. If >> you want to use it, I've got nothing against it, it's just a matter of how >> much effort you'd like to put into it for the benefits. I find that the >> current technique of grabbing the entire screen, comparing and sending the >> differences is what has worked best so far, with no artifacts and lost >> updates. With all other techniques, I never could get it right 100% of the >> time, there would always be cases where I'd get lost updates (portions of >> the screen being teared, or not updated, etc). Feel free to experiment and >> come up with alternative techniques, as long as you can write detection >> code to see if they are suitable. There's enough code right now to detect >> most possible features anyway. >> >> As for the cursor, I say take a look at the invalidated regions that get >> encoded. A blinking cursor will cause updates, but I wouldn't suspect it to >> cause more than a small region to be updated. >> >> Best regrds, >> - Marc-Andre >> >> On Fri, Oct 24, 2014 at 4:16 PM, Ryan Bair <ryandb...@gmail.com> wrote: >> >>> Thank you Marc, useful information. >>> >>> I did some exploring with XDamage today and the information returned >>> seems sane on my setup (Intel hd3000, gnome-shell/mutter, Fedora 20). I >>> might do some exploring and make it an opt-in feature. >>> >>> I noticed on master that my WAN upstream (all 1Mbit of it) is being >>> saturated with just a blinking cursor. Know anything about that? I'll try >>> to chase that down, I'm guessing we're sending more than needed. >>> >>> On Fri, Oct 24, 2014 at 3:34 PM, Marc-André Moreau < >>> marcandre.mor...@gmail.com> wrote: >>> >>>> Hi Ryan, >>>> >>>> xdamage usage is currently disabled in the X11 shadow server subsystem >>>> because it is not working correctly. In the vast majority of modern X11 >>>> environments, xdamage is totally useless and reports the entire screen as >>>> being invalidated on every pixel change. This happens with compositing >>>> window managers. It is possible to get somehow valid information from >>>> xdamage in certain cases, like unity 2d, but even then there are many >>>> possible bugs in xdamage that may result in incorrect information being >>>> reported. >>>> >>>> The current code does not require xdamage, it makes a comparison >>>> between the last screen frame capture and the next one and encodes what has >>>> truly changed. It is surprisingly fast. With enough effort, we could still >>>> leverage xdamage in certain cases, but there just wasn't enough interest to >>>> push it further. >>>> >>>> Best regards, >>>> -Marc-Andre >>>> >>>> >>>> On Thu, Oct 23, 2014 at 10:49 PM, Ryan Bair <ryandb...@gmail.com> >>>> wrote: >>>> >>>>> I found some unused code which makes use of XDamage but is no longer >>>>> used. >>>>> There are two commits that removed the functionality: >>>>> >>>>> >>>>> https://github.com/FreeRDP/FreeRDP/commit/d9d9bf36094ba41e0d52defa18b8b424ef3d0e83#diff-2db5bd5d07a97902247410cfb1d7c8a1 >>>>> >>>>> >>>>> https://github.com/FreeRDP/FreeRDP/commit/fdab87cba084af83232c9a5d9b2ca2e8569e426a#diff-2db5bd5d07a97902247410cfb1d7c8a1 >>>>> >>>>> Can anyone shed light on the history of this or if its worth while to >>>>> attempt to re-enable XDamage/Fixes? I know some compositing window >>>>> managers >>>>> had issues a while ago but I thought we had that all behind us. >>>>> >>>>> Thanks, >>>>> -Ryan >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> _______________________________________________ >>>>> FreeRDP-devel mailing list >>>>> FreeRDP-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/freerdp-devel >>>>> >>>> >>>> >>> >> > ------------------------------------------------------------------------------ _______________________________________________ FreeRDP-devel mailing list FreeRDP-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
