HiDPI and uidescription?

Excellent! Thanks!

This is working for me now, except for one issue: if I call setZoomFactor or setZoom multiple times with the same value (2.0), it gets larger, and larger, and larger…

This causes a problem if I close my plug-in window and later re-open it, because after my GUI is re-created, I check if I need hi-res support turned on, and if so, then call setZoomFactor(2.0). (Otherwise I call setZoomFactor(1.0).)

This is strange, because it should only set it to 2.0 or 1.0, since that’s all my code ever sets it to. It shouldn’t get larger than what I set it to in this manner. Right?

Ok, that’s working now, but I notice that the COptionMenu doesn’t scale when the rest of the GUI scales. It maintains the system setting (at least on the Mac), so the text is really small when I run on a hi-res monitor. Is there any way around this? I am using a menu item to turn on or off the hi-res feature of our plug-in, so if I can respond to that with some call to fix up the menus as well, that would help. (For our dialogs, I suppose I’ll have to write two of them, in different sizes.)

Or should I leave dialogs and menus alone, since the fonts used are set by the user at the system level, and are their responsibility to set so that they can read it on their own monitor?

I’m not really sure I understand you here. If you don’t change the scale of the CFrame on Mac, you get the native one. So if your editor is on a HiDPI screen, it get’s a scale of 2 automatically. Then the popup menus are also correctly scaled.
If you change the scale via CFrame::setZoom() programmatically then yes the popup menu won’t scale with it.
And what are your dialogs ? Are these views set via CFrame::setModalView() ? Then you don’t have to anything.

I don’t see this behavior. I have to call setZoom (or setZoomFactor()) myself, at least in Cubase 9.0.0.85 on the Mac. Perhaps it is because I have dual monitors, and it always detects the one with normal dpi (regardless of which monitor I have my main menu bar attached to)? How can I run a test such where one monitor is normal dpi and one is hi dpi and get the results you describe?

Updated to 9.0.20. Same behavior. Cubase comes up very small on my big monitor, and my plug-in comes up in normal (small) size, with tiny menus and dialogs. I thought maybe selecting Zoom from the main menus would fix it, but that only performs a “maximize” on the window, and doesn’t increase the sizes of any of the components or menus.

Maybe you have set the flag “Open in Low Resolution” in the Finder Info of the Cubase app ?

I don’t see any such option in the Get Info screen for Cubase. And looking at some recent posts, hi-dpi mode does not appear to be supported on Mac in Cubase 9. If it is, it’s certainly not working here (in 9.0.20.209), and I don’t see any way to turn it on.

It’s not working in Studio One 3, either, but I see some steps outlined on their forums for resetting the preferences to get that option to show up. I will try that.
[EDIT] High-DPI mode only works on Windows for Studio One 3.

Cubase on macOS does support HiDPI since at least 8.5. On Windows, Cubase still does not support HiDPI.
I don’t know why you get what see. For me I see this for the Finder Info for Cubase 9 :

Here is mine:
Screen Shot 2017-08-15 at 7.41.07 AM.png

It seems that the issue isn’t even as simple as needing double-sized bitmaps for hi-res screens. Apparently, Mac laptop users now have “Retina” screens, which have the ability to be hi-resolution, but because of their small size, they are used in lo-resolution mode for this kind of work. When doing so, it appears that the graphics are “zoomed” to make them bigger, so that our plug-in window is a usable size, but our normal-sized graphics look “blocky”, like zooming in in Preview.

Using double-sized images in such a situation makes the plug-in window too big, and requires me changing the size of the plug-in window, which is apparently why I was having problems getting things to work “automatically”.

If doubling the size of the images isn’t the fix for that situation, then I see that I can change the resolution (pixels/inch) in Photoshop, WITHOUT changing the image dimensions (in pixels). But how would I define such an image for users, given this scheme of naming things 2x, etc.? Which version of an image, exactly, would be used on a Mac laptop with a Retina display, used in 2k mode, (or any hi-res display used in low-res mode, for that matter)?

And if I need to support both hi-res monitors in hi-res mode, AND hi-res monitors in lo-res mode (as Mac laptops seem to be used most commonly), what sets of images do I need, at what sizes, and at what resolutions?

Sorry Howard, I cannot follow you. You seem to make things more difficult then it is.
You may can use the provided “editorhost” example in the latest SDK as this one also supports HiDPI on macOS and Windows to make your tests. As the source code of the host is provided you can go deep into it if needed.

Cheers
Arne

Well, it is difficult because there is no documentation on what to do. I need to know what to do to make the images that I will need for hi-res monitors. For my 2x images, do I make them double the size in pixels, or do I make them double the pixels-per-inch (Resolution, in Photoshop) while keeping the size the same?

You do as I said in my first reply: HiDPI and uidescription? - VSTGUI - Steinberg Forums

But that is what is not working when used on a high-res monitor set to a low-res setting. For example, a Retina laptop set at 2k resolution.
And it’s not working “automatically” in high-resolution mode in either Studio One 3 or Cubase 9 on my Mac. I had to add a menu item to call setZoom (or setZoomFactor), and then set the plug-in window size as well.

More specifically, when I run in Studio One 3 on my hi-res monitor in hi-res (4k) mode, my plug-in window is too small. It does not use my 2x bitmaps, unless I use a menu item in my plug-in to zoom. But that requires increasing the frame size as well, and my popup menu items are still tiny.

But when I run on my hi-res monitor in lo-res mode (2k), then my plug-in window is the expected size, and the popup menu items are correct. But it is still not using my 2x bitmaps for this. Rather, it uses the normal bitmaps. And in this scenario, any drawing I do in my graph (using the mouse) is wrong. While the coordinates are correct, the line widths appear to double.

On my normal lo-res (2k) monitor, everything is normal, but obviously it still doesn’t use the 2x bitmaps.

So I have yet to see any condition where the 2x bitmaps are used automatically.

I’m really not sure what you’re doing so that it is not working.
Try this :

    • Open the Displays System Preferences and set the Resolution to Default on an HiDPI screen.
  • Now start Cubase or Studio One and open your plug-in editor.
  • Make a screenshot of your editor.
  • Quit host
  • Change Display Resolution to scaled and the middle position
  • repeat open host and your editor and make screenshot

Now are the sizes of both screenshots the same ?

Yes, they are the same size. Neither one is using my 2x graphics. I added a bright yellow mark to my 2x background so that I can easily tell it from the original. (If I use my menu item to call setZoomFactor() myself, then it does show the 2x graphics with that yellow mark.)

If the screenshot sizes are the same, then the apps don’t run in HiDPI mode. I don’t know why you don’t get them to run in that mode, but that’s the issue you have to solve.

Ok, it’s working now. I had to set a system setting via the command line (DisplayResolutionEnabled) in order to see the HiDPI selection on my Mac desktop computer, which allowed me to select a HiDPI mode on my monitor. Now I am getting the 2x images I am supposed to see.

(Unfortunately, my non-Apple hi-resolution monitor still doesn’t have a HiDPI selection available for this testing for some reason, but I can use my regular monitor to see that the correct images are being used, and that’s enough for my development and testing purposes.)

Thanks for the help, Arne!