HiDPI in Windows 10

It unfortunately does not work in the same way as 9.5 when you disable HiDPI, it locks to 200% when you disable HiDPI (or presumably whatever you have your scale value to, and there is no way to disable this. (that i have found))

Can’t say my experience is the same. I’m running at 150% scaling on a 4k monitor and I just disable HiDPI and it looks like the usual.

sorry yes, if your ‘usual’ is 150 then disabling HiDPI will give you your ‘usual’ my usual is 100, when i set my scaling to 200, as I disable all scaling

I’m running on Win7 with 4k and 150% Windows scaling.

Cubase 10 doesn’t even -have- a HiDPI option in the General tab. Is this normal?

Cubase only supports the HiDPI mode on Windows 10.

Hope this helps.

Oh, I thought only the problems were on Win10.

I’ll upgrade 1-3 months before Win7 EOL, purely on security grounds. The fallout from the move is not to be undertaken lightly

Thanks for the info!

Arne, why just Windows 10 is supported while Windows 7 has basically the same HiDPI support?

No, Windows 7 and Windows 10 have totally different HiDPI implementations. For example there no support for multiple displays with different DPI on Windows 7, but that’s only one of many things missing in Windows 7.

Cheers,
Arne

Most of Windows-API features are cumulative. So everything available in Windows 7 is also available in more recent Windows versions, so support in W7 and W10 cannot be totally different, it can be just extended in W10.

Per-Monitor DPI Awareness is not as important as support for HiDPI itself. For basic DPI awareness, all you need is:

  • determine pixel ratio by dividing GetDeviceCaps(GetDC(window), LOGPIXELSX) by default 96;
  • multiply all the UI-element’s sizes and coordinates by that ratio with proportional upscaling of bitmap graphics where needed;
  • declare DPI awareness: either via executable’s manifest (<dpiAware>true</dpiAware>) or by calling SetProcessDPIAware().

Or does Cubase 10 use Windows 10’s automatic scaling stuff like EnableNonClientDpiScaling() without actually supporting true HiDPI?

Fwiw, according to StatCounter, market share of Windows 7 is 70% of Windows 10’s market share (36.31% vs. 51.94%). According to NetMarketShare, the difference is even smaller: Windows 7’s market share is 84% of Windows 10’s one (35.27% vs. 41.82%).

You’re funny, you want to tell me about HiDPI Windows API.
So if you’re interested read this: https://blogs.windows.com/buildingapps/2017/04/04/high-dpi-scaling-improvements-desktop-applications-windows-10-creators-update/
and this https://blogs.windows.com/buildingapps/2016/10/24/high-dpi-scaling-improvements-for-desktop-applications-and-mixed-mode-dpi-scaling-in-the-windows-10-anniversary-update/
and there is still more stuff that are only visible in the msdn docs about stuff not available in Windows 7.

Have a nice Weekend,
Arne

There is nothing funny or wrong in telling you about HiDPI Windows APIs given how long it took to implement HiDPI support in Cubase and how unreasonably limited it still is.

I’m aware of those HiDPI improvements in Windows 10. Is there something less broad and more specific you could say? What exact W10-exclusive HiDPI feature you use that is a blocker for basic Windows 7 support I described in my previous message?

And what about the huge market share of Windows 7?

Thanks.

I think you’re vastly underestimating the complexity of the situation with Cubase. It’s clearly not that they don’t know the APIs. There’s a technical debt in Cubase that is very hard to reconcile with Microsoft’s forward-looking hiDPI strategy, as opposed to Apple’s more pragmatic one.

I do think it’s a management issue though. There’s no excuse that after all this time the Windows version is in this condition. Yes it likely requires a lot of gruelling redesign to support it properly, but it should have been done at this point if you want to advertise this as one of your main features.

Regarding Windows 7 support, I have to imagine people using a legacy OS with modern hardware is such a niche group that any extra work to support that combination makes no financial sense. Mainstream support is already gone and extended support is ending in 2020. It makes perfect sense to target Windows 10 only for this feature.

I have a Windows 7 (what I work in) and Windows 10 boot (slowly migrating)
with a 55" 4k TV and two regular 22" monitors.
I see no difference at all in clarity. Excatly the same in Win10 with HiDpi enabled in C10.
Am I doing something wrong?

I have them set up as follows -

Windows 10
HiDpi enabled in C10 pref/general
55" at 3840x2160 set to 125% in windows setting, main display
Both 22"s at 1680X1050 set to 100% in windows setting, extended displays

Windows 7
Windows 7 set to 125% under Display/make text and other items larger or smaller
All monitor resolutions the same as in Win10 above

Sure. It’s just much easier to tell that Windows 7 does not support HiDPI (or that W7/W10 support for HiDPI is “totally different”) to a non-programmer than to someone like me who has some understanding and experience in programming C++/WinAPI DPI-aware applications with Windows 7 support.

I’m not sure what you mean.

Absolutely.

There is probably a wrong assumption here. For example, my PC is from 2011, and its performance is still quite enough today even for 4K.

Hardware upgrades are often partial: e.g. I replaced my original i3-2100T CPU to i7-3770T with the same socket and no need for changing anything else including Windows version; I replaced my graphics card to GTX 650 Ti Boost in ~2013. Then bought a 4K monitor in 2015, and my graphics card already had the DisplayPort port required for 4K@60Hz.

None of those partial hardware upgrades forced me to change my Windows version. This is not a niche situation, this is a regular situation corresponding to the nature of the open PC architecture available since IBM-compatible PCs appeared.

The only issue with HiDPI in Windows 7 that could be called serious was that Windows Explorer had unusable proportions of address bar and search box at Windows zooms more than 188% (I use my 4K monitor at 200%). But I successfully overcame the issue with the ExplorerHiDpiFix utility developed by myself.

Focusing an application development solely on new users and ignoring interests of existing users may be something relatively appropriate with other types of software, but this is probably not reasonable in long term as for professional musical software. Unfortunately, Steinberg already did this when removed the Cubase-VST-project-import feature from Cubase (SX) 4+ (though long-term Cubase users have tons of old projects), and continued to go the same way when stopped supporting 32-bit systems in Cubase 9+ (though musicians have tons of projects that use old discontined 32-bit-only VST plugins).

But the crucial detail with HiDPI support in Cubase 10 under Windows 7 is that Windows 7 itself is still supported, it’s just HiDPI support that is missing in Cubase 10 under Windows 7. And as long as HiDPI support is implemented properly, it is unreasonable to support HiDPI under Windows 10 and not support it under Windows 7 at the same time.

Windows 7 won’t magically stop working once its support is ended. Support just means security updates, but those updates are not necessary for Windows itself to function in the first place. Moreover, many professional musical computers are not even connected to Internet, so there is no risk for them in not getting updates, and many musicians don’t even care. So Windows 7 will most likely keep being used and popular far longer than until 2020.

Even Windows XP is still used, and some big russian software developer — 1C — has even recently created (article in Russian) a custom version of the WebKit engine (built into their software) to prevent losing Windows XP users. There are software developers that set a high value on their long-term users.

I’ll just post here a screenshot.

The settings
Resolution: 5431 × 3055
Scaling: 200%
NVIDIA DSR - Factors: 2.00x (native resolution)
NVIDIA DSR - Smoothness: 35%
HiDPI in Cubase: On

The elements of Cubase and plugins looks fantastic, not tiny, not huge (but only with the hack I done with NVIDIA DSR Factors and Smoothness).
Native Instruments sucks, some of the plugins are not usable (Bite, Choral, Replika XT).

Try this for all Windows 10 users :-

Enter Settings
System
Display
Advanced scaling settings
Let Windows try and fix apps so they’re not blurry. Switch to On
Enter a custom scaling size between 100%-500% (Not recommended) Type in the scaling size you are using on you 4K HD Monitor, in my case 125%.
Switch Off HiDPI.
OK its not super clear as it should be but at least it is usable until they fix it.

Solved my problem and I hope it works for you. Please note I accept no responsibility if your PC throws a wobbly LOL. I repeat it worked for me :slight_smile:

@Quietly
I tried that as well, but it has other downsides, like plugins not displayed properly with Windows 125% setiings. And I’m not talking of minor rarely used plugins, but including plugins from UAD and others. That made me revert to Windows 10 100% settings, with other workaround efforts required. NONE of all these workarounds is working flawless with Cubase 10.5 Pro, as it should. So getting Cubase AND all plugins displayed properly is clearly a Steinberg job with highest priority!

I find it extremely annoying to use a complex DAW while constantly being reminded of it’s display setting weaknesses, concerning all the most used nowadays resolutions! And yes, am really getting impatient and annoyed meanwhile, waiting to see this fixed finally. To Steinberg: You can’t seriously offer HiDPI and leave it utterly halfbaked for many months to come! A HiDPI setting which is not scaleable is no proper HiDPI at all.

Sorry I forgot to mention switch off HiDPI. OK its not the answer but at least its readable and not blurry. I agree its still a mess and I hope it gets fixed on the next update because I refuse to pay to get something that I already have paid for.

Unfortunately this isn’t just a steinberg issue it’s the plugin devs. Here’s a quote about it from Pete who works for Microsoft on the issue.

Yes. DPI awareness is a long bugbear. I hate seeing blurry content, and I also hate seeing tiny content on a high DPI display. It’s a lot better than it was at the initial release, but that’s because Windows has done just about all the automatic stuff it can do. It’s up to app developers to handle the rest.

If Windows had a single set of system controls that all apps used, it wouldn’t be a big deal. But we support a LOT of different ways to get pixels on the screens, the most popular of which are 20-30 years old at this point. Some plugins, for example, use OpenGL, or UI libraries built on that. I’ve had discussions with the teams involved, and the complexity of doing this from Windows, in a way that works for everything without breaking some apps, is a non-trivial computer science problem.

In the meantime, we provide the following info to partners/ISVs trying to deal with this. The reality is, though, that some app developers just don’t care because they don’t hear complaints from their users.

https://docs.microsoft.com/en-us/win...ectedfrom=MSDN

There’s also some stuff in there that app authors can do to then set up a child window (VSTs, for example) to use bitmap scaling. That’s also not guaranteed to work 100% of the time, but luckily, VST UI is a much more constrained ecosystem (not in terms of UI libraries used, but the idea that resizing is a no-go to begin with, so bitmap-based resizing is possible for many).

In any case, the team continues to work on this with each release of Windows, but there are diminishing returns at this point. It’s really up to the app developers. We do have tech in Windows that handles this properly and automatically, but it’s currently available only to UWP apps. That’s changing, but I don’t expect DAW app developers to rewrite their UIs to use the more modern stack.

(BTW, I’m assuming you’ve tried the compatibility options in the app’s shortcut menu: right-click a pinned icon, choose properties. Click the compatibility tab and then “Change high DPI settings”).

Pete

While I can agree with most of what you are saying the simple fact is that most apps work perfectly in other DAW’s with HiDPI enabled. Namely Studio One 4, Ableton Live, Reaper, Bitwig which does suggest that it is more a Steinberg issue than an app developers one but obviously not in all cases. Bottom line I can use can use any of the DAW’s I mentioned with my VST’s, HiDPIswitched on, screen scaling at 125% or 150% without any problems I just want Steinberg to allow me to do the same.