DPI awareness

[Markus Krause]

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

[Vokbuz]

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]

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+

[Vokbuz]

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

[Youlean]

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

Yes.

[Markus Krause]

Yes on PC. No on Mac.

[Tale]

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

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

[Vokbuz]

Yes on PC. No on Mac.

On Mac you don't need special settings to support high resolution.

[syntonica]

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.

[Vokbuz]

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

[mystran]

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.

[Wallander]

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.

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.

[JCJR]

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?

[Wallander]

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.