Funky window drag move on Windows 10 v2004 #4636
Comments
|
Can you please provide your system info? You can run Help->System info from PrusaSlicer, then select "Copy to Clipboard" and paste it here.
|
|
Can confirm, trying to drag the window is very, very slow. |
|
Can also confirm, window lags behind movement and moves in an odd way. Problem also present in the 2.3.0 alpha release! |
|
I was able to reproduce it on this system. Detailed system info attached.
|
|
Are you guys aware when this started to happen? Was it after some Windows update? EDIT: just confirmed on another PC, that it started to happen after 2004 update |
|
I got it after update to windows 10 2004 also, but I didn't see it initially. The reason I didn't get it from start, was that I had set my config to show the settings in separate windows instead of tabs. If I, in prefernces, set it to show the settings as the "old" way with tabs, it gets sluggish. So if I set the preferences to show the settings in modal windows, it the sluggishness dissapears. I am not at home right now, so I cant check the correct name for the preferences and send screenshots, but they are only available in the 2.3.0 branch. It is not available in 2.2.0 which I could test here at work (2.2.0 release is also slow since windows 10 2004.) |
|
It seems to be a breaking change after Windows 10 update in a way how WIN32 API presents the message queue during the window movement. bool wxMSWEventLoopBase::Pending() const PeekMessage seems to return "Idle" even if the user drags the window around like a crazy monkey, even though the message queue should be full of mouse events. As our application redraws from OnIdle handler, this causes our application window to lag behind the mouse cursor as if on a long soft rubber band. We will likely modify our rendering behavior between the windows specific wxWidgets callback EVT_MOVE_START / EVT_MOVE_END. I have reported this issue to wxwidgets list, but I think this time the Redmond guys are guilty. |
|
Hmm, the above does not seem to apply, I was wrong. @jmd73 Thanks for the hint, we can reproduce that. When the parameter editor is floating, the parameter editor shows this rubbery effect when moved while the main application is moved swiftly. |
|
I am having the same effect with a 3 years old Slic3r PE on Windows build 2004, if I add couple more extruders, for which parameter pages are generated. For some reason, the Windows 2004 build does not like the sheer amount of Win32 controls at our parameter pages. We are considering to reduce them by custom rendering some of the static texts, images and the undo buttons. I would complain to Microsoft, but I don't know where. |
|
I have reported to Microsoft using the Windows 10 built in Feedback Hub application. If you want Microsoft to fix it, please log into the Feedback Hub and upvote the following report: Rubber band Window movement on Windows build 2004 After update to Windows build 2004, our Win32 application PrusaSlicer This is the issue opened by our customers. I debugged the application and it really hangs inside the Win32 default window handler routine when dragging a window, our application does not hang inside our handler. Our application creates a form with 1300 Win32 windows split into three tabs and multiple pages, see the attached screenshot. Most of the Win32 controls are hidden most of the time, however even these hidden windows seem to cause this rubber band window dragging effect. If we lower the number of Win32 controls 6x, the issue is fixed, however we did not have this issue before the build 2004 update. |
|
@bubnikv I can't upvote it, since I can't find it on the feedback hub. The search function is, in my opinion, not very good. Update on the feedback hub problem. I still can't find your report @bubnikv. Did you have english as "language" selected in the feedback hub? I can choose between swedish and english, if I choose either I don't get results in the other language. |
|
I'd like to confirm the rubber band effect on dragging the window. Also occurs on previous Win 10 Releases. Updated my Workstation last weekend to 1909 - same effect as on my 2004 main PC. |
|
@jmd73 We have a solution prepared for PrusaSlicer 2.3 by @YuSanka, where the controls are populated on demand. It solves the rubber band window movement, but the switching of parameter pages is slower. @YuSanka will work on improving speed of switching the parameter pages. God knows what the Microsoft guys screwed in the Windows build 2004. |
|
The issue will be fixed in PrusaSlicer 2.3.0-alpha1. |
|
@bubnikv Do you know of a specific commit or PR in which this was fixed? Experiencing the same issue in another project with wxWidgets and am interested in how you mitigated it. I went through the commits but couldn't find anything. Thanks. |
|
@forkineye I believe it was done between 398ff90 and b17c829. I'm not sure if you'll be able to take something from it. As far as I know, the main trick is to only create the controls on the current tab and destroy them when switching elsewhere, @YuSanka would know the details. |
|
@forkineye As far as I can remember, the issue was solved magically by replacing the wxWidgets notebook control with out own control. We did that mainly due to dark mode support as we were not able to skin the Win32 notebook properly. |
Version
2.2.0+win64
Operating system type + version
Windows 10 64bit version 2004
3D printer brand / version + firmware version (if known)
Doesn't matter
Behavior
Dragging the main window by the title bar shutters and is very delayed, laggy.
Is this a new feature request?
No
Project File (.3MF) where problem occurs
Happens with any models (even with a clean install and empty scene)
The text was updated successfully, but these errors were encountered: