Plugin GUI scaling on high DPI displays

I’m running 5.12 on Linux using high DPI displays, a MacBook retina display and a small 4k monitor. The UI of Ardour itself scales perfectly. From my initial testing, it seems like the native UIs of plugins run at a fixed resolution, and it doesn’t seem possible to scale or maximize them, regardless of plugin type (vst, lv2, etc.). An example of this I’ve tested is the plugin Dexed. Helm, another synth plugin, has similar behavior, and interestingly, its standalone version will indeed scale itself to fit a maximized window. I haven’t looked at the code yet, but it seems like it should be possible to allow this kind of scaling inside Ardour. Is this all expected behavior for the current implementation or am I just missing something? I’d appreciate a counterexample plugin that will scale if someone knows of one, just so I can figure out exactly what’s happening.

There’s nothing that can be done about this by the plugin host. Plugins draw their own GUIs, not the host. Ardour’s GUI scales because we use vector graphics, not pre-rendered images or fixed-scale drawing. We do not “magnify” or “shrink” the GUI. This sort of GUI implementation can be a big deal … a couple of releases back, FL Studio made a big deal about how all of its GUI was now scalable … because it had not been before.

Thanks for clarifying, Paul. How does Ardour decide how large the native plugin window should be? Is the plugin responsible for reporting this to the host? Or does the host just hand control to the plugin and let it draw its window? I understand that certain plugins may actually be using raster, some vector, etc. Helm for example seems to actually have a vector GUI implementation under the covers, but somehow its rendering behavior is different when run inside a host, i.e. somehow it makes a decision to render at a particular scale. Even in the raster case I would prefer a UI that was scaled up in the naive way (just by doubling etc) and pixelated to a UI that is unusable at its native resolution. Feel free to point me to the relevant part of the code base if that’s easier, and I can answer my own questions that way.

The infamous plugins (that have UIs) are all scalable. That has always been a priority for me.

The plugin is given a window, and does what it wants with it. In Ardour’s case, we wrap/nest that window inside our own, and we also intercept key and mouse events (mostly they are just passed onto the plugin). What gets drawn inside the window is the responsibility of the plugin - if it fails to draw anything, for example, then its window will be blank. It is also responsible for responding to window resize events.

You won’t find any code that would help you get what you want inside Ardour. As far as we are concerned, the visual contents (pixels) of the plugin’s window don’t exist / are not accessible to us.

The only part that may be relevant is the window resizing, and that code varies depending on the plugin type/platform in question.

1 Like

Really helpful information. Thank you. I must have just failed to find a plugin that properly responds to resize events in the nested host window context. Ssj, when you say that your plugins are scalable you mean that they respond to resize events and redraw themselves when loaded in Ardour? Looking forward to trying them out. Perhaps I’ll be able to apply similar ideas to other plugins I’m interested in.

I added UI scaling to my plug-ins a while back, you can also ‘live-resize’ the window to whatever you want. How well this works with host applications is mainly down to the host application. All host applications do something different - and odd, mostly it works, but (live) resizing was never part of the (VST2) standard so has always been a bit of a hack. VST3 actually has support for resizing (in as much as there is a sensible API) but (as usual) almost all host applications put their own interpretation on it which means it may or may not work as expected. In my opinion, high DPI remains a bit of a mess from a (plug-in) developer point of view (especially as the plug-in is running inside a host application which may or may not support it and may / may not advertise this correctly to the OS, depending partly on which OS / version). I’m currently relying on CPU rendering for most of my plug-in UIs which puts a limit on performance for huge resolution screens, so e.g. after about x4 we hand back to the OS on Mac and hope it makes a reasonable job of it - which means performance / quality may vary on some 'retina’™ displays (I have written some opengl shaders for high quality scaling, but so far opengl is not proving a compatible enough option across all platforms). In order of preference (from a developer point of view) I’d say Macs handle high DPI properly (you just render in ‘points’ and the points represent however many real pixels they need to at the OS level). Windows… It’s complicated… but mainly because of legacy OS compatibility requirements etc - though there are hundreds of compatibility settings, so you can normally find something that works, and Linux… well, I’ve heard it’s possible…
If you want to run High DPI (or anything) on a Mac, your best option is to use macOS.

By the way, the generic plugin UI is a great idea. I’m almost almost happy to just use that and the problem is solved in high dpi because Ardour’s UI scales. To be honest, from a weird creative point of view, it’s kind of nice to program a plugin just looking at its raw parameters and listening to the result. But sometimes a plugin depends on more complicated UI interaction that is hard to use without using its native interface. Maybe that’s again just on the plugin author to do something sane. Maybe I’ll look into how the generic UIs work a bit more. It would be cool if it were capable of capturing even more of these edge case plugins UI interactions somehow.

Ssj, when you say that your plugins are scalable you mean that they respond to resize events and redraw themselves when loaded in Ardour?

Yes, This screenshot ( ) shows a little bit that it supports resizing and even changes in aspect ratio. It worked for all linux hosts at one time, but there have been reports of it not working in certain hosts anymore. I haven’t checked with ardour lately. I’m slowly working on a UI rewrite that should resolve this, so I’m not addressing it in the current code.