[Bug 57175] New: Multiple issues with Audacity after upgrading to Wine 9.17
https://bugs.winehq.org/show_bug.cgi?id=57175 Bug ID: 57175 Summary: Multiple issues with Audacity after upgrading to Wine 9.17 Product: Wine Version: 9.17 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: aros(a)gmx.com Distribution: --- Created attachment 77073 --> https://bugs.winehq.org/attachment.cgi?id=77073 Audacity 3.6.3 in Wine 9.17 with DPI=144 and classic Windows theme After I upgraded Wine from version 9.10 to 9.17, Audacity has become horrible to use and look at. I've always been using DPI=144 because I have a High DPI 14" monitor. So, * Fonts in Audacity have become much smaller than they were before * Fonts now look very blurry A screenshot will be attached. On the outside of Audacity you can see IrfanView which continues to scale properly and fonts are rendered just fine. -- 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=57175 Artem S. Tashkinov <aros(a)gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source URL| |https://github.com/audacity | |/audacity/releases/download | |/Audacity-3.6.3/audacity-wi | |n-3.6.3-32bit.zip -- 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=57175 --- Comment #1 from Artem S. Tashkinov <aros(a)gmx.com> --- I could make a wild guess this is due to "Window surface scaling on High DPI displays" but then the regression range is huge. -- 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=57175 Artem S. Tashkinov <aros(a)gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #77073|0 |1 is obsolete| | --- Comment #2 from Artem S. Tashkinov <aros(a)gmx.com> --- Created attachment 77074 --> https://bugs.winehq.org/attachment.cgi?id=77074 Audacity 3.6.3 in Wine 9.17 with DPI=144 and classic Windows theme -- 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=57175 --- Comment #3 from Artem S. Tashkinov <aros(a)gmx.com> --- Also Wine spams: "024c:err:font:alloc_font_handle out of realized font handles" in console and I've no idea if it's a functional issue. -- 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=57175 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon(a)codeweavers.com --- Comment #4 from Rémi Bernon <rbernon(a)codeweavers.com> --- The DPI awareness is now application dependent, and some applications which are system or per-monitor DPI aware are going to keep the original scaling behavior. Applications which aren't DPI-aware are scaled to the configured system DPI through a bilinear upscale. This is similar to what Windows does, although it maybe has more advanced scaling options which aren't implemented yet. We could also perhaps add a registry setting to give the option to force the old behavior on all applications, but it is not how Windows behaves and it can break some other applications. -- 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=57175 --- Comment #5 from Artem S. Tashkinov <aros(a)gmx.com> --- (In reply to Rémi Bernon from comment #4)
The DPI awareness is now application dependent, and some applications which are system or per-monitor DPI aware are going to keep the original scaling behavior. Applications which aren't DPI-aware are scaled to the configured system DPI through a bilinear upscale.
This is similar to what Windows does, although it maybe has more advanced scaling options which aren't implemented yet. We could also perhaps add a registry setting to give the option to force the old behavior on all applications, but it is not how Windows behaves and it can break some other applications.
Is it possible to disable this new Wine's feature completely or for this application alone in Wine 9.17 or I just have to downgrade for a while? -- 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=57175 --- Comment #6 from Artem S. Tashkinov <aros(a)gmx.com> --- Secondly, bilinear scaling is so 2000. Could you perhaps implement something more modern, e.g. B-Spline, Lanczos or ewa_lanczossharp found in mpv? **At the very least it would be nice to see Integer Scaling (nearest-neighbor) in Wine.** Oftentimes it looks better than any advanced floating point upscale algorithms because it's just sharp. And it's pretty much de-facto for console emulators. -- 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=57175 --- Comment #7 from Rémi Bernon <rbernon(a)codeweavers.com> --- There won't be much of a difference with any other kind of filtering, the application draws at a lower resolution and whatever we can try to do about won't restore the missing information. Nearest neighbor gives very horrible results in this case, as it's not an integral upscaling (well except if you use a multiple of the base 96 DPI). -- 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=57175 --- Comment #8 from Artem S. Tashkinov <aros(a)gmx.com> --- (In reply to Rémi Bernon from comment #7)
There won't be much of a difference with any other kind of filtering, the application draws at a lower resolution and whatever we can try to do about won't restore the missing information.
Nearest neighbor gives very horrible results in this case, as it's not an integral upscaling (well except if you use a multiple of the base 96 DPI).
There's a world of difference between e.g. bilinear and lanczos: https://bugzilla.mozilla.org/show_bug.cgi?id=1547612 https://bugzilla.mozilla.org/attachment.cgi?id=9061254 -- 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=57175 Artem S. Tashkinov <aros(a)gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Multiple issues with |HiDPI support in Wine 9.17 |Audacity after upgrading to |results in multiple |Wine 9.17 |applications being blurry | |(Audacity, Far File | |Manager, others) --- Comment #9 from Artem S. Tashkinov <aros(a)gmx.com> --- Far File Manager 3.0.6300.0 is also affected :-( It's because blurry as hell in 9.17. -- 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=57175 --- Comment #10 from Artem S. Tashkinov <aros(a)gmx.com> --- s/because/become/ -- 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=57175 --- Comment #11 from Artem S. Tashkinov <aros(a)gmx.com> --- Created attachment 77086 --> https://bugs.winehq.org/attachment.cgi?id=77086 Far Manager 3 in Wine 9.17 -- 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=57175 --- Comment #12 from Artem S. Tashkinov <aros(a)gmx.com> --- I would love to disable this feature altogether. Is there something I can comment out in Wine to revert to the pre 9.17 behavior? -- 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=57175 --- Comment #13 from Rémi Bernon <rbernon(a)codeweavers.com> --- You can restore this line: https://gitlab.winehq.org/wine/wine/-/merge_requests/6396/diffs?commit_id=5b... -- 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=57175 --- Comment #14 from Rémi Bernon <rbernon(a)codeweavers.com> --- https://gitlab.winehq.org/wine/wine/-/merge_requests/6499 should probably help with FAR. FWIW I checked Audacity on Windows, and it has exactly the same behavior and is just as blurry as on Wine now when scaling is used. This is something that the application needs to implement, and it may be as simple as adding an executable manifest that advertises system DPI awareness, not something that Wine can fix. Sure, we could in theory try to implement smarter upscale filters, but that would need specific code, and I'm not yet sure it's worth it, and may be possible to do differently. -- 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=57175 --- Comment #15 from Artem S. Tashkinov <aros(a)gmx.com> --- Another fall out from HiDPI support, bug 57195. -- 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=57175 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gizmo_1979(a)yahoo.it --- Comment #16 from Rémi Bernon <rbernon(a)codeweavers.com> --- *** Bug 57193 has been marked as a duplicate of this bug. *** -- 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=57175 --- Comment #17 from Artem S. Tashkinov <aros(a)gmx.com> --- wineconsole and Far File Manager blurriness and repainting issues are now fixed as of bug report 57195. -- 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=57175 --- Comment #18 from Artem S. Tashkinov <aros(a)gmx.com> --- (In reply to Rémi Bernon from comment #13)
You can restore this line: https://gitlab.winehq.org/wine/wine/-/merge_requests/6396/ diffs?commit_id=5bebb24108954f763acb36175fff99e159f7536c#85770a8b187bd82db4db b9a2b8a5f34616049d0f_4928_4928
Sadly Wine 9.17 doesn't have this extract :-( What it has is: /* FIXME: what do the DpiScalingVer flags mean? */ get_dword_entry( (union sysparam_all_entry *)&entry_DPISCALINGVER, 0, &dpi_scaling, 0 ); if (volatile_base_key && dispos == REG_CREATED_NEW_KEY) /* first process, initialize entries */ { for (i = 0; i < ARRAY_SIZE( default_entries ); i++) default_entries[i]->hdr.init( default_entries[i] ); } -- 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=57175 --- Comment #19 from Rémi Bernon <rbernon(a)codeweavers.com> --- Yes, the line has been removed you need to add it back if you want all applications to be system DPI aware. Change: ``` /* FIXME: what do the DpiScalingVer flags mean? */ get_dword_entry( (union sysparam_all_entry *)&entry_DPISCALINGVER, 0, &dpi_scaling, 0 ); ``` to: ``` /* FIXME: what do the DpiScalingVer flags mean? */ get_dword_entry( (union sysparam_all_entry *)&entry_DPISCALINGVER, 0, &dpi_scaling, 0 ); if (!dpi_scaling) NtUserSetProcessDpiAwarenessContext( NTUSER_DPI_PER_MONITOR_AWARE, 0 ); ``` -- 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=57175 --- Comment #20 from Artem S. Tashkinov <aros(a)gmx.com> --- Created attachment 77089 --> https://bugs.winehq.org/attachment.cgi?id=77089 Wine 9.17 patch to disable HiDPI support (In reply to Rémi Bernon from comment #19)
Yes, the line has been removed you need to add it back if you want all applications to be system DPI aware.
This works, thanks a ton! I've made a patch for those who want to fix Wine 9.17 in the meantime. Looking forward to the official solution whatever it might be. -- 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=57175 Artem S. Tashkinov <aros(a)gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|HiDPI support in Wine 9.17 |HiDPI support in Wine 9.17 |results in multiple |results in multiple |applications being blurry |applications being blurry |(Audacity, Far File |(Audacity, OPT Design |Manager, others) |Assistant, wineconsole, | |others) -- 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=57175 --- Comment #21 from GizMo79 <gizmo_1979(a)yahoo.it> --- (In reply to Rémi Bernon from comment #14)
https://gitlab.winehq.org/wine/wine/-/merge_requests/6499 dovrebbe probabilmente aiutare con FAR.
Per quel che vale, ho controllato Audacity su Windows e ha esattamente lo stesso comportamento ed è sfocato come su Wine ora quando si usa il ridimensionamento. Questa è una cosa che l'applicazione deve implementare e potrebbe essere semplice come aggiungere un manifesto eseguibile che pubblicizzi la consapevolezza DPI del sistema, non qualcosa che Wine può risolvere.
Certo, in teoria potremmo provare a implementare filtri di fascia alta più intelligenti, ma ciò richiederebbe un codice specifico e non sono ancora sicuro che ne valga la pena; potrebbe essere possibile fare diversamente.
My thought is, if Windows does something but does it poorly... and it's possible to do it better than Windows without losing compatibility with programs, why not do it? I have at least 7 programs that I use, and before this update, they worked wonderfully with Wine, even with fonts at 120dpi. Now everything looks terrible. Please put things back the way they were before... Anyway, I've never seen Windows blur the fonts of programs. -- 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=57175 Jinoh Kang <jinoh.kang.kr(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jinoh.kang.kr(a)gmail.com --- Comment #22 from Jinoh Kang <jinoh.kang.kr(a)gmail.com> ---
We could also perhaps add a registry setting to give the option to force the old behavior on all applications, but it is not how Windows behaves and it can break some other applications.
Not exactly "force the old Wine behavior", but Windows has AppCompatFlags\Layers registry key to control app compatibility behavior (including GDI scaling). https://ss64.com/nt/syntax-compatibility.html -- 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=57175 --- Comment #23 from Austin English <austinenglish(a)gmail.com> --- The content of attachment 77073 has been deleted for the following reason: private info -- 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=57175 --- Comment #24 from GizMo79 <gizmo_1979(a)yahoo.it> --- (In reply to Jinoh Kang from comment #22)
We could also perhaps add a registry setting to give the option to force the old behavior on all applications, but it is not how Windows behaves and it can break some other applications.
Not exactly "force the old Wine behavior", but Windows has AppCompatFlags\Layers registry key to control app compatibility behavior (including GDI scaling).
Couldn't we put a checkbox in Wine's graphic configurations to enable and disable, so if one chooses whether to see badly or well? -- 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=57175 MarcinZw <marcinzw(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marcinzw(a)gmail.com --- Comment #25 from MarcinZw <marcinzw(a)gmail.com> --- Unfortunately, I have a problem with this change as well. Applications with high DPI settings are not only blurred but also very slow. For example, when I use WinDjView https://windjview.sourceforge.io/en, the scrolling performance is terrible, whereas at the standard 96 DPI, and with the proposed patch, it's quite fast. Integer upscaling would also be a nice addition, provided it doesn't slow things down like bilinear upscaling... -- 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=57175 --- Comment #26 from GizMo79 <gizmo_1979(a)yahoo.it> --- I don't know why, but since this bug doesn't seem to affect video games, I have a feeling it will remain unresolved for years, like other bugs I've reported that were completely forgotten because they relate to work and productivity applications... The Wine team seems to care only about video games... In the end, those who game on Linux typically use Steam's Proton at best... They should give more consideration to things that aren't video games. For now, I've forced the second-to-last version of Wine and blocked the packages to prevent updates. -- 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=57175 --- Comment #27 from MarcinZw <marcinzw(a)gmail.com> --- I understand that DPI awareness should be enabled by applications, but many older applications work very well with higher DPI settings. In fact, I consider it a "feature" that breathes new life into these older apps. I'm not suggesting it should be enabled by default, but it should be an option, perhaps accessible through the registry. -- 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=57175 --- Comment #28 from Rémi Bernon <rbernon(a)codeweavers.com> --- Please be patient, I intend to fix this but I want to see if we can do it the same way as Windows. -- 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=57175 --- Comment #29 from MarcinZw <marcinzw(a)gmail.com> --- Thank you for the update! I appreciate your efforts. -- 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=57175 --- Comment #30 from Rémi Bernon <rbernon(a)codeweavers.com> --- Since 6f44677c5fbc6b9677a72e27b8cb0a6e494dfad6 we now have support for the AppCompatFlags registry setting, as documented in <https://ss64.com/nt/syntax-compatibility.html>. The setting can be set per-user (HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers) or globally ( HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers). It can then be set for individual application (using the application path as the value of the registry entry), or globally (using the default registry value '@' for the key). The data can either be set to DPIUNAWARE or HIGHDPIAWARE, to force application DPI awareness to off or on respectively. -- 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=57175 --- Comment #31 from Artem S. Tashkinov <aros(a)gmx.com> --- (In reply to Rémi Bernon from comment #30)
Since 6f44677c5fbc6b9677a72e27b8cb0a6e494dfad6 we now have support for the AppCompatFlags registry setting, as documented in <https://ss64.com/nt/syntax-compatibility.html>.
The setting can be set per-user (HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers) or globally ( HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers).
It can then be set for individual application (using the application path as the value of the registry entry), or globally (using the default registry value '@' for the key).
The data can either be set to DPIUNAWARE or HIGHDPIAWARE, to force application DPI awareness to off or on respectively.
A welcome change, thanks a ton! Are there plans to hack winecfg to make these things visual and manageable by the average Joe? -- 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=57175 --- Comment #32 from GizMo79 <gizmo_1979(a)yahoo.it> --- I add myself to the request, you need a flag in winecfg to be checked to manually force the applications that create problems. -- 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=57175 --- Comment #33 from Rémi Bernon <rbernon(a)codeweavers.com> --- I'll consider it. In the meantime you can use the same command-line as is documented. For instance forcing all applications to be HiDPI aware: wine REG.exe ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /T REG_SZ /D "~ HIGHDPIAWARE" /F -- 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=57175 --- Comment #34 from Jinoh Kang <jinoh.kang.kr(a)gmail.com> --- (In reply to Rémi Bernon from comment #33)
I'll consider it. In the meantime you can use the same command-line as is documented. For instance forcing all applications to be HiDPI aware:
wine REG.exe ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /T REG_SZ /D "~ HIGHDPIAWARE" /F
/VE. :-) -- 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=57175 --- Comment #35 from MarcinZw <marcinzw(a)gmail.com> --- Thank you! It works for me. In the meantime, I looked into how Windows handles high DPI settings. It appears that Windows simply upscales the interface, but not the entire window. Only the toolbar and menu are upscaled, while the content rendered by the program remains unaffected. For example, in WinDjView, the interface is upscaled, but the displayed book is not. This explains why, even in my Windows virtual machine, scrolling is as fast as it is on Linux with 96 DPI or the DPI-aware option enabled. -- 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=57175 --- Comment #36 from MarcinZw <marcinzw(a)gmail.com> --- By the way for me only works for "HKEY_CURRENT_USER" (HKCU instead of HKLM) i.e. wine REG.exe ADD "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /T REG_SZ /D "~ HIGHDPIAWARE" /F -- 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=57175 Maciej Stanczew <maciej.stanczew(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maciej.stanczew(a)gmail.com -- 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=57175 John <svartchimpans(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |svartchimpans(a)gmail.com --- Comment #37 from John <svartchimpans(a)gmail.com> --- Oh. I was running Satisfactory with DX12 renderer (in Wine 9.21) and couldn't understand why the graphics were EXTREMELY pixelated despite the game being set to 3840x2160. Then I remembered this ticket and thought "could it really be running in low-DPI mode"? I ran this command: wine REG.exe ADD "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /T REG_SZ /D "~ HIGHDPIAWARE" /F Voila, Satisfactory now renders at native 4K again. -- 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=57175 --- Comment #38 from Artem S. Tashkinov <aros(a)gmx.com> --- (In reply to Rémi Bernon from comment #33)
I'll consider it. In the meantime you can use the same command-line as is documented. For instance forcing all applications to be HiDPI aware:
wine REG.exe ADD "HKLM\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /T REG_SZ /D "~ HIGHDPIAWARE" /F
This doesn't help for Audacity 3.7.1 but the patch still works in 10-rc3. I've also tried: ~ DPIUNAWARE ~ GDIDPISCALING DPIUNAWARE ~ HIGHDPIAWARE None of the works. -- 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=57175 --- Comment #39 from GizMo79 <gizmo_1979(a)yahoo.it> --- I have solved my problems with "REG.exe ADD "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /T REG_SZ /D "~ HIGHDPIAWARE" /F" but I still think it would be useful to have a checkbox in wineconfig to enable or disable this feature. Regardless of Windows' behavior with certain old applications, the result of disabling this function is significantly better usability. -- 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=57175 wine_bugzilla(a)sctb.ch changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wine_bugzilla(a)sctb.ch --- Comment #40 from wine_bugzilla(a)sctb.ch --- Morning, Gents. I am on Debian with XFCE and last night I updated and upgraded, and then as with others here, I found Wine apps now running at the wrong resolution (and so for windowed apps, blurry, and for full-screen apps, the apps was showing the normal resolution about 2.5k by 1.5k, but the *display* looked to be 640x480, so top-left corner only of the app could be seen), and running very slowly. Wine was then unusuable, and I was at a loss as to what had happened or why. After about 20 or 30 minutes of experimentation and Googling, I found this thread, tried to make the solution work but to begin with failed, but in the end achieved success with; "REG.exe ADD "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers" /T REG_SZ /D "~ HIGHDPIAWARE" /F" (But that HKCM specifically did not work - I needed HKCU.)
From my point of view, Wine was broken after update, and needed 30 minutes of Googling to fix. If this were to be a common experience, it would cause substantial disruption.
Finally, note there is one new problem; from the single full-screen app I use, I can now alt-tab to the Linux desktop exactly *once* before the display of the app goes black, i.e. the screen display is now simply a black screen, and so the app must be killed from the Linux command line and then restarted. It used to be I could alt-tab quite a bit, maybe ten times, but in the end textures would not load, and then I would need to quit (which I could do in the normal way, and restart.) -- 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=57175 --- Comment #41 from Jinoh Kang <jinoh.kang.kr(a)gmail.com> --- (In reply to wine_bugzilla from comment #40)
Finally, note there is one new problem; from the single full-screen app I use, I can now alt-tab to the Linux desktop exactly *once* before the display of the app goes black, i.e. the screen display is now simply a black screen, and so the app must be killed from the Linux command line and then restarted.
It used to be I could alt-tab quite a bit, maybe ten times, but in the end textures would not load, and then I would need to quit (which I could do in the normal way, and restart.)
This seems to be a separate issue. Can you file a bug for that, ideally with bisected 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.
https://bugs.winehq.org/show_bug.cgi?id=57175 --- Comment #42 from wine_bugzilla(a)sctb.ch ---
This seems to be a separate issue. Can you file a bug for that, ideally with bisected regression?
Done. -- 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=57175 Zdeněk Kopřivík <zdenek.koprivik(a)post.cz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zdenek.koprivik(a)post.cz -- 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=57175 Darkwood <stasvernon(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stasvernon(a)gmail.com --- Comment #43 from Darkwood <stasvernon(a)gmail.com> --- Hi, Is it possible to add a documentation page showing the effect (with screenshots please) of "Applications which aren't DPI-aware are scaled to the configured system DPI through a bilinear upscale."/DPIUNAWARE key? Given that one has to mess with the registry, its currently very hard to determine which apps could benefit from the bilinear upscale. BTW I couldn't find any example of such a setting PER APP in this thread. Does bilinear upscale increase the window size in physical screen dimensions? Thanks. -- 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