Community
Participate
Working Groups
Moving a Shell with a lot of controls is very slow. The Shell seems to lag behind the cursor movement. It is nearly impossible to quickly drag the shell around due to the severe lag. The issue can be reproduced by simply running the SWT examples project as documented here: https://www.eclipse.org/swt/examples.php Just launch the ControlExample and try to move the Shell around. We got similar reports for our application so it seems not to be bound to a specific SWT version. Might be cause by a recent Windows Update? I my case i am running Windows 10 20H2 / Build 19042.964
(In reply to Michael Heiss from comment #0) > specific SWT version. Might be cause by a recent Windows Update? Very likely. > I my case i am running Windows 10 20H2 / Build 19042.964 As i don't seen such issue with: Windows 10 20H2 / Build 19042.928
Created attachment 286322 [details] Video showing the slow, laggy movement Tried to capture the delayed / slow / laggy movement but the video does not really show it. I grabbed the Window and tried to move it as quickly as possible. For comparison i also moved the terminal window. At least the difference is visible :) Seems that the OS is not capable to draw the window that fast.
i tried to make a smaller example and with the following snipped it results in the same 'rubberbanding' when dragging the shell around. (its just a dummy example, the buttons are not placed in the layout) Windows 10 20H2 19042.928 public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setText("Snippet 1"); for (int i = 0; i < 250; i++) { Button x = new Button(shell, SWT.NONE); x.setText("" + i); } shell.setLayout(new StackLayout()); shell.setMinimumSize(500, 500); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); }
(In reply to Michael Heiss from comment #2) > Created attachment 286322 [details] > Video showing the slow, laggy movement > > Tried to capture the delayed / slow / laggy movement but the video does not > really show it. I grabbed the Window and tried to move it as quickly as > possible. For comparison i also moved the terminal window. At least the > difference is visible :) > > Seems that the OS is not capable to draw the window that fast. Thanks for the additional details. Could reproduce the issue with ConrolExample.java now, but it's not easily reproducible. Laggy movement isn't seen from the start. Only if you persistently and slowly move the shell for some time and only after few seconds the lag(rubber-band effect) is seen.
It seems to be directly related to the mouse poll rate. Benq has a simple online poll rate checker: https://zowie.benq.com/en-us/support/mouse-rate-checker.html The touchpad of my laptop seems to have 140hz. Using just the touchpad i don't expire the rubber-banding. My G203 Mouse seems to have around 1000hz by default. Using this mouse i expire the rubber-banding when running the ControlExample. When adjusting the poll-rate from 1000 down to 125 hz using the Logitech G Hub, the rubber-banding is gone. I guess the handling of those mouse events should be looked at in swt, maybe they can somehow be optimized for > 200hz poll rates?
Created attachment 286481 [details] better screencast, real vs lagging cursor i made another screencast which shows the current behavior better. You will see 2 cursors, one on the real position and the one lagging behind while dragging the window. At the end i can move the cursor freely while the swt window still tries to follow the drag. The dragging speed is really just a normal movement, not especially fast. In the eclipse console, you see the messages processed in Control#windowProc(), i think its interesting, that after i stop dragging, the window still moves but no new messages are processed until the EXITSIZEMOVE/SETCURSOR appear when the drag fully finished. So i would currently think that we poll the messages fast enough, but the processing somehow is very slow in certain circumstances. And maybe it would be possible to discard old/outdated movement messages which are sill being processed, if we receive a newer movement msg. 250 hz poll rate (0 lag with 150 hz) win 10 20H2 19042.985 ryzen 7 3700x cpu
I found an issue in a non-java project (c++) which describes a very similar behavior: https://github.com/prusa3d/PrusaSlicer/issues/4636 They seem to have noticed it after upgrading to windows 10 build 2004, which seems about right (released about a year ago). An interesting comment: https://github.com/prusa3d/PrusaSlicer/issues/4636#issuecomment-682412231 "PeekMessage seems to return "Idle" even if the user drags the window around..." Maybe that can be a point to look into. It could also be completely unrelated, but it sounds very similar.
it definitely started with windows version 2004 (19041), its not reproducible with 1909. (verified with 2 vm's). Currently the only workaround currently is to disable 'Show windows contents while dragging' in the windows performance options.
