DPI awareness

DSP, Plug-in and Host development discussion.
Markus Krause
KVRist
273 posts since 2 Jul, 2018

Post Mon Nov 11, 2019 8:33 pm

This seems to be undocumented, but seems to be used by a couple of hosts/plugins.

If my vst 2.4 plugin has a GUI with several zoom factors should i return 1 when
cando("supportsViewDpiScaling") is called?

What hosts do support this?

Thanks in advance,
Markus
Tone2 Audiosoftware https://www.tone2.com

User avatar
Vokbuz
KVRist
117 posts since 24 Aug, 2014 from Moscow

Re: DPI awareness

Post Mon Nov 11, 2019 11:41 pm

DPI and zoom factor are different things on some platforms. Why does host need to know that? Just call audioMasterCallback with audioMasterSizeWindow opcode when you want to change gui zoom factor.

Markus Krause
KVRist
273 posts since 2 Jul, 2018

Re: DPI awareness

Post Tue Nov 12, 2019 1:46 am

If the desktop zoom factor in win10 is set to 150% the software will be blury.
That's why a software can tell Windows that it is dpi aware. Then Windows 10 does not zoom. Instead the software itself handles it. This results in sharp graphics even when the zoom factor in Windows is set to a value different than 100%

I do not use openGL but Windows GDI+
Tone2 Audiosoftware https://www.tone2.com

User avatar
Vokbuz
KVRist
117 posts since 24 Aug, 2014 from Moscow

Re: DPI awareness

Post Tue Nov 12, 2019 2:56 am

If this setting is per application/process, the application cannot use different settings for different plugins, right?

User avatar
Youlean
KVRist
351 posts since 11 May, 2016 from Serbia

Re: DPI awareness

Post Tue Nov 12, 2019 4:09 am

Vokbuz wrote:
Tue Nov 12, 2019 2:56 am
If this setting is per application/process, the application cannot use different settings for different plugins, right?
Yes.

Markus Krause
KVRist
273 posts since 2 Jul, 2018

Re: DPI awareness

Post Tue Nov 12, 2019 5:24 am

Yes on PC. No on Mac.
Tone2 Audiosoftware https://www.tone2.com

User avatar
Tale
KVRian
501 posts since 12 Apr, 2010 from The Netherlands

Re: DPI awareness

Post Tue Nov 12, 2019 5:42 am

It would seem that on Win10 1607+ you can enable DPI awareness per thread, see:

https://docs.microsoft.com/en-us/window ... esscontext

User avatar
Vokbuz
KVRist
117 posts since 24 Aug, 2014 from Moscow

Re: DPI awareness

Post Tue Nov 12, 2019 6:35 am

Markus Krause wrote:
Tue Nov 12, 2019 5:24 am
Yes on PC. No on Mac.
On Mac you don't need special settings to support high resolution.

User avatar
syntonica
KVRian
545 posts since 25 Sep, 2014 from Specific Northwest

Re: DPI awareness

Post Tue Nov 12, 2019 8:41 am

Vokbuz wrote:
Tue Nov 12, 2019 6:35 am
Markus Krause wrote:
Tue Nov 12, 2019 5:24 am
Yes on PC. No on Mac.
On Mac you don't need special settings to support high resolution.
You should add "High Resolution Capable" to the properties plist. Since you pretty much need a Retina display Mac to run the latest OSes, I'm not sure if it's even still necessary.

But in answer too the OP's question, I just just scale my GUI myself and only use the window resize call and rescale if successful. I don't bother with the canDo, and to be honest, I didn't know it was there. I thought I had pored over the VST code regarding all the little odd bits, like which canDos are available to plugins.

User avatar
Vokbuz
KVRist
117 posts since 24 Aug, 2014 from Moscow

Re: DPI awareness

Post Tue Nov 12, 2019 9:14 am

I believe this is required when linking against very old SDKs. My macOS apps perfectly work with high-resolution without NSHighResolutionCapable.

mystran
KVRAF
5492 posts since 12 Feb, 2006 from Helsinki, Finland

Re: DPI awareness

Post Tue Nov 12, 2019 3:57 pm

Vokbuz wrote:
Tue Nov 12, 2019 9:14 am
I believe this is required when linking against very old SDKs. My macOS apps perfectly work with high-resolution without NSHighResolutionCapable.
No idea if this happens with plugins (probably not), but I've had some .app bundles randomly get locked into low-resolution mode unless the flag is present... and it's weird, because I've only seen it happen a few times and the same .app might have worked for weeks and it might have worked just fine 15 minutes earlier and then you restart (the application, not the system) and it's low-resolution for no apparent reason. Even when this happens, running the actual binary inside the bundle directly still works fine and if you manage to convince Finder that you have a new bundle with the same name, then it might (or might not) enable high resolution mode again (at least temporarily).

I don't really know much more than that, since once I added the flag into my Info.plist template, I've never seen this issue happen again. Maybe it's fixed in recent macOS versions, but whatever.
If you'd like Signaldust to return, please ask Katinka Tuisku to resign.

User avatar
Wallander
KVRist
91 posts since 13 May, 2007

Re: DPI awareness

Post Wed Nov 13, 2019 5:42 am

Markus Krause wrote:
Mon Nov 11, 2019 8:33 pm
This seems to be undocumented, but seems to be used by a couple of hosts/plugins.

If my vst 2.4 plugin has a GUI with several zoom factors should i return 1 when
cando("supportsViewDpiScaling") is called?

What hosts do support this?

Thanks in advance,
Markus
I can't remember exactly why, but I've actively commented out the "supportsViewDpiScaling" canDo. I'm only remembering this very vaguely, but I think that it didn't actually inform the host that your plug-in is natively high-DPI capable, but it rather made the host forcefully rescale the plug-in's window (blurry) going by the DPI. So a DPI setting of 200% would result in a 400% window, if you also had your own scaling.
mystran wrote:
Tue Nov 12, 2019 3:57 pm
No idea if this happens with plugins (probably not), but I've had some .app bundles randomly get locked into low-resolution mode unless the flag is present... and it's weird, because I've only seen it happen a few times and the same .app might have worked for weeks and it might have worked just fine 15 minutes earlier and then you restart (the application, not the system) and it's low-resolution for no apparent reason. Even when this happens, running the actual binary inside the bundle directly still works fine and if you manage to convince Finder that you have a new bundle with the same name, then it might (or might not) enable high resolution mode again (at least temporarily).

I don't really know much more than that, since once I added the flag into my <span class="skimlinks-unlinked">Info.plist</span> template, I've never seen this issue happen again. Maybe it's fixed in recent macOS versions, but whatever.
I would definitely choose to use NSHighResolutionCapable for standalones, but the flag is ignored for plugins.

If you suddenly delete that flag from your standalone's Info.plist file, I don't think you're going to get consistent behaviour, due to MacOS caching. But if you make a copy of the bundle, and launch the copy instead, that should launch the application as if new (you can then delete the original bundle, and rename the copy to the original name).

This workaround can also be used to force high-resolution support into someone else's app, e.g. a low-resolution DAW can be made high-resolution, meaning it will also open plug-ins in high-resolution. That is, if the DAW doesn't crash from suddenly being a high-resolution app without being prepared for it.

One way or the other, the flag is definitely in use, because it can be used to launch any application in low-resolution mode, by setting it to FALSE.
Arne @ noteperformer.com

JCJR
KVRAF
2896 posts since 17 Apr, 2005 from S.E. TN

Re: DPI awareness

Post Wed Nov 13, 2019 7:55 am

Wallander wrote:
Wed Nov 13, 2019 5:42 am
This workaround can also be used to force high-resolution support into someone else's app, e.g. a low-resolution DAW can be made high-resolution, meaning it will also open plug-ins in high-resolution. That is, if the DAW doesn't crash from suddenly being a high-resolution app without being prepared for it.
I don't keep up and it doesn't matter to debate, but wouldn't it perhaps happen that you could get daw behavior which opens high-res "normal sized" plugin windows, but opens all the native daw windows (on high res screens) the size of postage stamps, requiring a magnifying glass and world-class mouse control in order to use the native daw windows? :)

User avatar
Wallander
KVRist
91 posts since 13 May, 2007

Re: DPI awareness

Post Wed Nov 13, 2019 11:56 am

JCJR wrote:
Wed Nov 13, 2019 7:55 am
Wallander wrote:
Wed Nov 13, 2019 5:42 am
This workaround can also be used to force high-resolution support into someone else's app, e.g. a low-resolution DAW can be made high-resolution, meaning it will also open plug-ins in high-resolution. That is, if the DAW doesn't crash from suddenly being a high-resolution app without being prepared for it.
I don't keep up and it doesn't matter to debate, but wouldn't it perhaps happen that you could get daw behavior which opens high-res "normal sized" plugin windows, but opens all the native daw windows (on high res screens) the size of postage stamps, requiring a magnifying glass and world-class mouse control in order to use the native daw windows? :)
It would make sense if that property instructed the host to NOT scale the plug-in, labeling it as DPI aware. But as far as I can recall, that wasn’t universally the case.

EDIT: To answer your actual question, yes, you will get postage stamp interfaces in any high-DPI host on PC, loading DPI-unaware plugins. If you’re not getting this, it’s because the host uses a workaround to scale up plugin windows.
Arne @ noteperformer.com

Return to “DSP and Plug-in Development”