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
