I have an undecorated window that I want to move by dragging the panel inside. However under the scenario WindowDragNoDelay the window jumps erratically with the mouse position read incorrectly in Java (also printed to stdout).
Through debugging I've 2 scenarios (WindowDragWithDelay,WindowDragNoMove) that can return the mouse location correctly and 1 (WindowDragNoDelay) that doesn't.
As a control (CentOS without Xpra) WindowDragNoDelay will return the correct mouse location.
Reproduce by installing java and running the windowdrag.jar in attached zip file:
java -cp windowdrag.jar WindowDragNoDelay java -cp windowdrag.jar WindowDragWithDelay java -cp windowdrag.jar WindowDragNoMove
Can attach logs if you provide the log categories you want.
Python Client on Windows 10 (also can reproduce with HTML5 client) Server on CentOS 7. Client and server both on revision r20214
Sample jar and source
disable pointer adjustments
The patch above "fixes" the issue, but we can't apply it.
The problem comes from the fact that since the xpra server and client(s) can be detached and re-attached, each one has its own window model and each model can be different. For example, windows may not be shown on screen exactly where the server thinks they are. That's especially the case when you enable session sharing and connect with multiple clients.
So we keep track of where the clients map each window, and when we process pointer events from a client we adjust the position of the event so that it lands in exactly the same place on the server side window. When running your example code, we create a race condition: the server moves the window and sends a message to the client to do likewise but before the client has a chance to do so it has sent a pointer motion event which then gets adjusted for the new window position the client knew nothing about at that point.. So we shouldn't adjust it, and that's why the patch "works".
Thanks for the quick turn around and explanation, I've tested the patch and confirm it works as expected.
Our use case is single screens per user and sharing disabled so will probably be able to work something out from the patch.
Again really appreciated.
Re-opening: this bug should be fixed, just not with the patch above which was just there to show where the problem came from.
Correct fix in r20225, this was hard because everything is asynchronous, including X11 events, client-server messaging, etc So now the client keeps track of the delta between the window location requested by the server and what it actually is using at any point in time. It communicates this delta value with the server through the "map" and "configure" packets. Then the server can adjust pointer events with the correct delta, even if the window has moved since the last time the client got a move notification.
Still TODO:
ClientTray class could be updated so we can eventually replace the mapped_at attribute with just the delta, since the former is prone to race conditions
@mjharkin: your test case now works with this new code. You will need an updated client and server (2.4 beta r20225 or later, builds have been uploaded for mswindows, centos 7.4 and 7.5: https://xpra.org/beta/). This change is not suitable for backporting to older branches.
Note that this is not how you should be doing the window move from your Java code, as this is excruciatingly slow, even on local connections.
Instead of managing the window position yourself (which will happen server-side and cause the churn), you should be requesting that the window manager moves the window for you. This will happen client-side and will be smooth as silk. (though somewhat less smoothly on mswindows and macos than other platforms since we have to emulate the X11 window-manager-spec's _NET_WM_MOVERESIZE: #772)
This can be achieved on X11 with _NET_WM_MOVERESIZE, you can find an example we use for testing here: browser/xpra/trunk/src/tests/xpra/test_apps/test_window_initiatemoveresize.py
I can also confirm the test case works with r20225.
I've ran into 2 issues though:
disconnect: zlib packet decompression failed must be string or read-only buffer, not memoryview
Not sure if it's caused by these changes though.
2018-08-29 21:44:04,041 Warning: zlib is the only compressor enabled
2018-08-29 21:44:04,045 install and enable lzo or lz4 support for better performance
2018-08-29 21:44:04,049 Xpra gtk2 client version 2.4 64-bit
2018-08-29 21:44:04,058 running on Microsoft Windows 10
2018-08-29 21:44:04,071 Error: failed to load overlay icon 'C:\Users\Ultrabook\git\Xpra\trunk\src\build\exe.mingw-2.7\icons\xpra.png':
Traceback (most recent call last):
File "./xpra/client/mixins/window_manager.py", line 189, in init
File "C:/msys64/mingw64/lib/python2.7/site-packages/PIL/Image.py", line 64, in <module>
from . import _imaging as core
ImportError: DLL load failed: The specified module could not be found.
2018-08-29 21:44:04,097 DLL load failed: The specified module could not be found.
2018-08-29 21:44:04,104 Warning: failed to import opencv:
2018-08-29 21:44:04,108 No module named cv2
2018-08-29 21:44:04,112 webcam forwarding is disabled
2018-08-29 21:44:04,127 Error importing swscale colorspace conversion (csc_swscale)
2018-08-29 21:44:04,130 DLL load failed: The specified module could not be found.
2018-08-29 21:44:04,146 Error importing webp decoder (dec_webp)
2018-08-29 21:44:04,148 DLL load failed: The specified module could not be found.
2018-08-29 21:44:04,155 Error importing JPEG decoder (dec_jpeg)
2018-08-29 21:44:04,162 DLL load failed: The specified module could not be found.
2018-08-29 21:44:04,169 Error importing vpx decoder (dec_vpx)
2018-08-29 21:44:04,171 DLL load failed: The specified module could not be found.
2018-08-29 21:44:04,180 Error importing avcodec2 decoder (dec_avcodec2)
2018-08-29 21:44:04,182 DLL load failed: The specified module could not be found.
2018-08-29 21:44:04,267 get_pixbuf(information.png)
Traceback (most recent call last):
File "./xpra/client/gtk_base/gtk_client_base.py", line 532, in get_pixbuf
GError: Couldnâ?Tt recognize the image file format for file â?oC:\Users\Ultrabook\git\Xpra\trunk\src\build\exe.mingw-2.7\icons\information.pngâ??
...
Agreed this type of code is less than ideal but I'm constrained by a 3rd party. Funnily enough the 3rd party code is less efficient (more computation) than the test case but results in better performance for this scenario.
I dislike popping in to a random ticket, but r20225 introduces a serious mouse bug. I've double checked this with a bisection and r20225 is the guilty revision.
For reference, both the client and server are Fedora 28 machines running trunk Xpra built from source.
r20225 and newer sessions have a mouse offset - in that where the mouse is on the client does not reflect where the server sees the mouse. It's quite simple to reproduce:
dmesg to get a wall of text
On my machine - a non-fullscreen Xterm in this situation is unable to select any text that shows up. Making it go fullscreen - I see that the mouse is selecting text about 10 or so pixels below (about 4 lines of text at my DPI/resolution) where the client mouse is.
I can gather some -d mouse client and server side logs if you'd like - but it's very easy to reproduce and visualize what is happening.
disconnect: zlib packet decompression failed must be string or read-only buffer, not memoryview
Fixed: ticket:1926#comment:2.
Not sure if it's caused by these changes though.
It wasn't, but thanks for reporting it. (out of curiosity, what made you try the websocket transport? it is slower after all)
install and enable lzo or lz4 support for better performance
For lz4, see ticket:1929#comment:1. (patching required) For lzo, try this from a mingw shell:
python -c "import lzo"
Is it installed? Or did it not get packaged properly?
(try to run Network_info.exe -v)
Error: failed to load overlay icon ...(..)DLL load failed: The specified module could not be found.
Hmm. Things are not going to work well without Pillow and the codecs.
Maybe your system has a dependency that I don't have and it doesn't get packaged?
Are you fully up to date? (pacman -Syyu)
Try updating all the python libraries too:
sh win32/UPDATE_PYTHON_LIBS.sh
You can try to figure out which DLL is missing using Dependencies (a new "dependency walker") by pointing it to the "pyd" files that generate the DLL warnings. If you still have problems with this, can you follow up in #1883 or even a new ticket? (let's keep this ticket about pointer position)
r20225 introduces a serious mouse bug. I've double checked this with a bisection and r20225 is the guilty revision.
r20230 fixes this: when the client moves a window (or maps it), the server should only apply the delta value until the client catches up (if it ever does). Which means that this statement:
.. so we can eventually replace the mapped_at attribute with just the delta, since the former is prone to race conditions
Is wrong. We need to keep both.
@Antoine Martin
Now using lz4 as you described.
python -c "import lzo"
Gave an error (but not needed as I'll use lz4)
NameError: name 'lzo' is not defined
Still have an issue with Pillow. Am fully up to date on a clean install as per the Windows building guide. But will continue investigating and update the relevant ticket if needed.
For your interest we are using the websocket connection for 2 reasons:
Taking the ticket back: forgot reinit_windows (fixed in r20243) and this solution isn't going to work well with sharing enabled - I think I have a better plan.
Reverted r20225 + r20230 in r20249. Still working on a correct solution..
Related: r20252 + r20253 exposes window-relative pointer position in pointer-position and button-action packets, this may help and could actually simplify pointer adjustments when dealing with desktop and shadow servers: with those we never care about the position of the window on the client, only the relative coordinates are useful.
Too late for 2.4, this sort of change can break things.
#2008 could also be related to this bug.
Re-scheduling, might be easier to make any changes after #1942.
The revert was incomplete and caused a bug: #2249.
I was thinking that we could simply calculate the current window offset from the relative pointer coordinates, then adjust from that value. Not so easy I am afraid.
Tracking back:
_adjust_pointer method was generalized, recording where each client maps the window in the mapped_at attribute of window source object
_get_pointer_abs_coordinates method which means the disable-pointer-adjustment.patch "fix" no longer works - not sure why we need that: adjustments, if any are needed, should be in one place? Maybe this is for multi-window shadow servers?
So, we do want to use adjust_pointer when the window is mapped at a different location (ie: because the client's OS prevented it from overflowing), but not in other cases (ie: when we've just moved it and the client hasn't caught up yet...)
Damn. I was thinking of using another approach and let the client do all the adjustments to pointer coordinates, returning:
It would be easier because then there would only be limited logic on the server side, just using the server-relative coordinates when those values are provided by the client. The problem with this approach is that the client doesn't always know where the window is actually mapped on the server side: it could have been moved since, and when it sends a "configure" or "map" packet, the server may or may not honour it: only the server knows the actual window position to do the adjustments.
So the only viable solution is going to be something like r20225 + r20230 + r20243.
See also #2600, #2516, #2618, #2675, #2455. Raising.
FYI the zip file seems broken
FYI the zip file seems broken
Looks fine to me:
$ unzip WinDrag.zip Archive: WinDrag.zip creating: src/ (..) inflating: .classpath
I forgot that the /attachment/ does not give you the file e.g. when you wget it.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1941