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@winehq.org Reporter: aros@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
Artem S. Tashkinov aros@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
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #1 from Artem S. Tashkinov aros@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
Artem S. Tashkinov aros@gmx.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #77073|0 |1 is obsolete| |
--- Comment #2 from Artem S. Tashkinov aros@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
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #3 from Artem S. Tashkinov aros@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
--- Comment #4 from Rémi Bernon rbernon@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #5 from Artem S. Tashkinov aros@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?
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #6 from Artem S. Tashkinov aros@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #7 from Rémi Bernon rbernon@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).
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #8 from Artem S. Tashkinov aros@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
https://bugs.winehq.org/show_bug.cgi?id=57175
Artem S. Tashkinov aros@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@gmx.com --- Far File Manager 3.0.6300.0 is also affected :-(
It's because blurry as hell in 9.17.
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #10 from Artem S. Tashkinov aros@gmx.com --- s/because/become/
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #11 from Artem S. Tashkinov aros@gmx.com --- Created attachment 77086 --> https://bugs.winehq.org/attachment.cgi?id=77086 Far Manager 3 in Wine 9.17
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #12 from Artem S. Tashkinov aros@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?
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #13 from Rémi Bernon rbernon@codeweavers.com --- You can restore this line: https://gitlab.winehq.org/wine/wine/-/merge_requests/6396/diffs?commit_id=5b...
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #14 from Rémi Bernon rbernon@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #15 from Artem S. Tashkinov aros@gmx.com --- Another fall out from HiDPI support, bug 57195.
https://bugs.winehq.org/show_bug.cgi?id=57175
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gizmo_1979@yahoo.it
--- Comment #16 from Rémi Bernon rbernon@codeweavers.com --- *** Bug 57193 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #17 from Artem S. Tashkinov aros@gmx.com --- wineconsole and Far File Manager blurriness and repainting issues are now fixed as of bug report 57195.
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #18 from Artem S. Tashkinov aros@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] ); }
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #19 from Rémi Bernon rbernon@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 ); ```
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #20 from Artem S. Tashkinov aros@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
Artem S. Tashkinov aros@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)
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #21 from GizMo79 gizmo_1979@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
Jinoh Kang jinoh.kang.kr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jinoh.kang.kr@gmail.com
--- Comment #22 from Jinoh Kang jinoh.kang.kr@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
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #23 from Austin English austinenglish@gmail.com --- The content of attachment 77073 has been deleted for the following reason:
private info
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #24 from GizMo79 gizmo_1979@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?
https://bugs.winehq.org/show_bug.cgi?id=57175
MarcinZw marcinzw@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |marcinzw@gmail.com
--- Comment #25 from MarcinZw marcinzw@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...
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #26 from GizMo79 gizmo_1979@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #27 from MarcinZw marcinzw@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #28 from Rémi Bernon rbernon@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #29 from MarcinZw marcinzw@gmail.com --- Thank you for the update! I appreciate your efforts.
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #30 from Rémi Bernon rbernon@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #31 from Artem S. Tashkinov aros@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?
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #32 from GizMo79 gizmo_1979@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #33 from Rémi Bernon rbernon@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
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #34 from Jinoh Kang jinoh.kang.kr@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. :-)
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #35 from MarcinZw marcinzw@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #36 from MarcinZw marcinzw@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
https://bugs.winehq.org/show_bug.cgi?id=57175
Maciej Stanczew maciej.stanczew@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maciej.stanczew@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=57175
John svartchimpans@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |svartchimpans@gmail.com
--- Comment #37 from John svartchimpans@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #38 from Artem S. Tashkinov aros@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #39 from GizMo79 gizmo_1979@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.
https://bugs.winehq.org/show_bug.cgi?id=57175
wine_bugzilla@sctb.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine_bugzilla@sctb.ch
--- Comment #40 from wine_bugzilla@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.)
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #41 from Jinoh Kang jinoh.kang.kr@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?
https://bugs.winehq.org/show_bug.cgi?id=57175
--- Comment #42 from wine_bugzilla@sctb.ch ---
This seems to be a separate issue. Can you file a bug for that, ideally with bisected regression?
Done.
http://bugs.winehq.org/show_bug.cgi?id=57175
Zdeněk Kopřivík zdenek.koprivik@post.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zdenek.koprivik@post.cz
-
WineHQ Bugzilla