[Bug 57955] New: Ableton Live 12.1.10: Main interface is unusable
https://bugs.winehq.org/show_bug.cgi?id=57955 Bug ID: 57955 Summary: Ableton Live 12.1.10: Main interface is unusable Product: Wine Version: 10.3 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: pedrodarch15b(a)gmail.com Distribution: --- On both GNOME and KDE Plasma, the latest Live 12.1 window does very weird things with it's main window. What I can best describe it as is, for some reason it stretches itself down vertically by what's seemingly the size of what would be the title bar of the application. When running Live with window manager decorations / control enabled under Wine configuration, this causes the application window to bounce up and down very rapidly, bringing most of my machine's CPU time with it. This makes the whole application practically unusable. When running on a virtual desktop, the stretch-up-and-down-sorta movement does not happen, however, with the main window stretched downwards, mouse clicks and things respond a few pixels off vertically, and the application is not usable in this state. Interestingly, the same doesn't happen on Live's subwindows, such as the settings window or anything else really Prior to Live 12.1.5 this could be mitigated by using a hotkey to make Ableton run full screen. With recent Ableton updates this doesn't seem to work anymore. Note: disabling HiDPI mode in Live's settings doesn't make the problem go away Note: dxvk had to be installed on the prefix so that non-main windows aren't rendered black (this should probably be reported in another bug) Tested on Live Trial 12.1.10, download URL is https://cdn-downloads.ableton.com/channels/12.1.10/ableton_live_trial_12.1.1... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57955 --- Comment #1 from Pedro M Sanches <pedrodarch15b(a)gmail.com> --- Created attachment 78202 --> https://bugs.winehq.org/attachment.cgi?id=78202 video showing the issue on a virtual desktop -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57955 --- Comment #2 from Pedro M Sanches <pedrodarch15b(a)gmail.com> --- Created attachment 78203 --> https://bugs.winehq.org/attachment.cgi?id=78203 video showing the issue on kde plasma (window manager decor & control enabled) going full screen still seems to alleviate the problem -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=57955 johnstonljordan(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |johnstonljordan(a)gmail.com --- Comment #3 from johnstonljordan(a)gmail.com --- This is actually a big REGRESSION. Somewhere between 9.0-rcX and 9.0 this menu issue and the main window not being rendered correctly was introduced. Wine-8.21 and earlier do NOT have this issue at all. It's easy to confirm this bug and that it is a regression by installing Wine-8.21 - where Ableton Live main window renders correctly, and works as expected. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=57955 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=57955 Alex Henrie <alexhenrie24(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Version|10.3 |5.5 CC| |alexhenrie24(a)gmail.com, | |rbernon(a)codeweavers.com Regression SHA1| |47f69a22484a5b0c1286cb0f430 | |976d97fa6d9a0 Component|-unknown |winex11.drv --- Comment #4 from Alex Henrie <alexhenrie24(a)gmail.com> --- I use the Cinnamon desktop and I am seeing what looks like the same bug with Ableton Live, but it's a much older regression. `git bisect` says: 47f69a22484a5b0c1286cb0f430976d97fa6d9a0 is the first bad commit commit 47f69a22484a5b0c1286cb0f430976d97fa6d9a0 Author: Rémi Bernon <rbernon(a)codeweavers.com> Date: Wed Mar 18 14:46:07 2020 +0100 winex11.drv: Remove frame when non-client area is empty. Several applications -Steam, Battle.net for instance- handle the WM_NCCALCSIZE message to override the non-client areas size and make the client area cover the whole window, instead of changing the styles. In winex11.drv, in decorated mode, we adjust the window rect according to the window style to hide the unwanted decorations behind the frame, but when client and window rects are equals, there's nothing to hide and the actual window styles are irrelevant and can safely be ignored. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=40930 Signed-off-by: Rémi Bernon <rbernon(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> You'll need `winetricks vcrun2019` if you want to test Ableton Live on such an old version of Wine. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=57955 --- Comment #5 from Rémi Bernon <rbernon(a)codeweavers.com> --- In its window procedure WM_WINDOWPOSCHANGED handler the application does: dpi = GetDpiForWindow(hwnd); style = GetWindowLongW(hwnd, GWL_STYLE); ex_style = GetWindowLongW(hwnd, GWL_EXSTYLE); menu = GetMenu(hwnd); RECT adj = {0}; AdjustWindowRectExForDpi(&adj, style, menu != 0, ex_style, dpi); RECT client; GetClientRect(hwnd, &client); client.right += (adj.right - adj.left); client.bottom += (adj.bottom - adj.top); client.bottom += 4; SetWindowPos(hwnd, 0, 0, rect.right, rect.bottom, SWP_NOMOVE); This causes the window rectangle to grow vertically until it reaches the maximum vertical window size. At that point, the application stops doing this, but also ends up returning a client rect == window rect from its WM_WINDOWPOSCHANGING handler, which causes the window decorations to be removed. Depending on the window size and on the Linux window manager decision, this can even end up in a infinite window decoration addition / removal loop, which makes the application fully unusable. The latter part is probably just a bogus behavior caused by reaching a corner case and I suspect that the issue comes from the client.bottom += 4 adjustment that is being made in the first place and which triggers the vertical growth. I don't really understand why that adjustment is being made but I suspect it is related to the menu bar itself. On windows the menu is styled differently, and I think the adjustment is meant to compensate some missing vertical size that AdjustWindowRect doesn't or should take into account. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla