I’ve recently rediscovered Audacity, after I’ve heard about it over 10 years ago. Now I didn’t want to install that 20 years old audio editor on my new Windows 10 computer and decided to use Audacity.
That computer is a Surface Pro 4 with 2736 pixels screen resolution at about 12". That makes a regular text scaling of 200%. That additional sharpness of the screen is incredible! Text, many graphics and other elements appear almost like real. Going back to my normal desktop 24" screen makes me immediately notice every single pixel.
Audacity unfortunately doesn’t care for DPI at all and gets rendered at half resolution by Windows. Each pixel you draw takes up 4 pixels on my screen. That’s very much noticeable because it stands out from the rest of the desktop so badly. I have very few applications that perform so badly, most just have minor bitmap scaling issues here and there but generally do well. I’m glad that my device has 200% and not 150% where everything would be very blurry.
I’ve found traces of the High DPI support feature request in the Audacity Wiki but not much at all. That makes me wonder if anybody is still thinking of that “feature” (I might call it a bug) and has some plan about it? Does anybody of you have a screen that just can’t be operated at 100% and also runs into this behaviour?
You should be careful throwing around the “B” word.
“Unintentional, evil behavior, experienced by multiple people”…etc.
It’s doing precisely what it was designed to do.
We run into overly simple screen handling all the time on the forum. That doesn’t exactly fit, either. By the time you get the screens comfortable to use and clear to read, graphics, screen caps and illustrations become grotesque.
Well, my reasoning is that it is (or likely will be) bugging me. Nobody can say that isn’t true. I don’t know if it fits your official definition of a “bug” however.
Actually my main point was asking whether this has been forgotten or is being worked on. I didn’t find it in any kind of issue tracker, just a veeery long list in a wiki that probably won’t ever be read again. (I know that kind of issue management in a long text file, it always fails.) All other software I use already supports this hardware for a while or has been updated recently to do so. Just not Audacity. I’m sure you have this situation on OS X “retina screens” as well for quite some time, but I don’t know how it’s handled there.
We run into overly simple screen handling all the time on the forum. That doesn’t exactly fit, either. By the time you get the screens comfortable to use and clear to read, graphics, screen caps and illustrations become grotesque.
Well, my reasoning is that it is (or likely will be) bugging me.
In development, it’s a little like opening the conversation inquiring whether your mom got married yet. Off on the wrong foot.
In defense, while it seems perfectly desirable to drudge in the display system, Audacity supports all three major platforms and the last Windows and Mac “upgrades” have been, let’s say, challenging. The Mac one is developing extreme power saving (my new MBA is expected to go 12 hours without a charge and I see no reason to doubt it) but it does it by taking semi-damaging shortcuts. The Windows update is a different operating system. If your Windows worked before, that’s no guarantee of future success—or even that your machine will survive the upgrade.
So in the face of damaged recordings and out and out machine crashes, having awkward screen resolution may not seem so bad.
Very limited resources and time is a constant problem, so unless the correction drops off the list completely, it’s still in consideration. There is a hierarchy listing that gets regularly visited and updated.
We live for the days when an experienced developer arrives and offers to help produce Audacity corrections or fixes for actual Bugs. Wanting to be a developer doesn’t count. Nobody’s running a school.
I am, but not for C++ code. I call C# and the .NET platform my home, that’s a lot easier. I’m not so much familiar with developing for platforms other than Windows either. So I’m probably not much of a help in this project. (In fact I gave up half way reading through your compilation instructions.)
About the Windows “upgrade” from 7/8 to 10, that’s not an upgrade, it’s a reinstall. And it’s almost always a bad idea. But that’s nothing Aduacity is responsible for, that’s Microsoft’s issue. When I’ll upgrade my desktop PC from 7 to 10, I’ll do a fresh install. So for me, seeing a degraded rendering is currently the one most prominent issue. That’s what I wanted to say.
Bugs such as not all elements of the Audacity interface being capable of DPI scaling and Audacity not being HiDPI capable are not on our bug tracker as far as I know. We get few complaints and so fixing this (probably a major undertaking) isn’t a high priority versus other improvements we could nake for the same effort.
Also some of the HiDPI omissions will lie in wxWidgets code and not the Audacity code. There are separate wxWidgets versions for Mac and Windows, and I “think” Retina support has improved in 2.1.2 because 2.1.2 uses a later wxWidgets version where Retina support is better.
Are you running Audacity with the “Disable display scaling on high DPI settings” compatibility option enabled? As I understand it, this would prevent fonts looking blurred, but graphical elements will be far too small. Is that what you observe? I don’t have high resolution monitors.
Probably the only way our HiDPI support will improve is if a developer who has an appropriate monitor or tablet and cares about the issue is prepared to fix it. If you were able to help us improve this on Windows only, that would be fine.
I have installed Audacity and not changed any settings yet. What I see is a UI with correct proportions of everything, just not as sharp/detailed as it could get.
As I read it, Audacity requires wxWidgets 3.0. The current version 3.1, released a few months ago, has improved high dpi support on Windows, according to their website. Maybe this is an easier first step?
Actually I’m not a fan of compiling C++ code because it takes forever, the source code probably doesn’t compile with the Visual Studio version I have installed (2015), sometimes doesn’t compile even when it should, and third-party libraries leave directories on my disk in places where they don’t belong (e.g. the root directory). Oh, I see you’re patching others’ code, too. Why can’t there just be “one build script” that does it all? How do you configure your CI build server?
The setting I spoke of “Disable display scaling on high DPI settings” is a Windows setting (right-click over audacity.exe, Properties, Compatibility tab).
I assume from your description that the checkbox for that setting is not enabled, and that if you did enable it, so disabling scaling, you would get sharper fonts but some graphical items would be too small.
If you mean lib-src, see audacity-patches.txt in that directory in the source code for the reasons.
You can certainly build wxWidgets at the command-line with nmake if you want to.
“Why can’t?” is the usual reason in open source projects - volunteer resources. It is hoped to automate Windows building at some time (as we do for Mac, and as Travis CI does for us on Linux for checking for build-breaking).
Yes, that compat setting was deactivated. When I activate it, I get mostly correct high-res text and native controls (buttons, checkboxes, sliders etc.), partly too small layout (windows, UI elements, textboxes etc.) and all bitmap graphics are too small, resulting in tiny toolbars and other elements. So it looks like some window layout calculations need an additional factor and the bitmaps need to be scaled or provided in higher resolution.
