Host Scaling not reflected in plugin window scaling on X11, maybe on Win32 #359

Hi, I have been building a CLAP and VST plugin Host for the Godot game engine (4.5+) as an Open Source Extension.
Setup is : Arch Linux Laptop + 2 differently scaled Ext. Monitors, KDE w/ Scaling - testing in Reaper plus my own Godot extension.

If I scale the host's UI the plugin's editor doesn't follow. Host and editor disagree on size, with the expectation that Host should take priority over System over safe fallback of 1.0, since the Host in theory directly informs the plugin of their scale...
(CLAP set_scale, VST3 setContentScaleFactor).
Reaper never calls set_scale, so it isn't affected, but I'm trying to follow the CLAP guidelines., and so I see it in X11 with Xft.dpi set in my own host.
I can't just trust Xft.dpi, as that is Global, but my monitors are different, and only the Host knows which window the editor window is placed on.

What the plugin APIs say

• CLAP call order, gui.h L19-L33: set_scale (7) → get_size (10) →
  set_parent (11).
• CLAP set_scale, gui.h L141-L152, quote: "Set the absolute GUI scaling factor, and override any OS info."
  It also says that it may be ignored, but then "Returns false if the call was ignored", so either way the host must be told the truth, and so it reads like the default intent is "follow the host".

What baseview does

• Host value is a fallback: scale_factor() L157-L167
• It takes Xft.dpi first; handle_host_suggest_scale_factor L111-L125
• It returns early when Xft.dpi exists.

It is documented that way:

• suggest_fallback_scale_factor L115-L133

• WindowSettings::fallback_scale_factor

• Win32 has the same idea, the host value is used I think only under per-monitor v1 awareness
  (dpi.rs L126-L127).

macOS: no-op (logical, I think this one is fine - but can't test).

• Returns Ok(()) whether used or not (window.rs L130-L133).

Why that breaks hosts with the current call chain
The nice-plug CLAP set_scale returns true on Ok (wrapper.rs L2980-L3002);

VST3 makes the same call (view.rs L800).

This means that the host is told the scale was "applied" successfully, and so it lays out at its own scale, while the editor draws at the Systems. My Host has no way to know, as far as I can see, what's real.

Another bug in the same logic, measured using Xvfb and without Xft.dpi

In plugin creation: with_size(400x300).with_fallback_scale_factor(2.0) you get 400x300 physical at scale 2, i.e. half the requested size, permanently

[sizing.rs L141-L153] (

Re-sending a scale doubled the window each time when there is no Xft.dpi, triggered by moving the window between monitors etc: fixed in my open PR #358.

Context, and proposal
It's in the same vein as as Issue #324 (PR #329), NativeSize helper for better integration with VST3/CLAP APIs.

• (1) report whether a suggested scale was applied (Result<bool, _> or an enum), so frameworks can answer set_scale truthfully
• (2) an authoritative setter to guarantee the host's scale can win

I understand that Plugins are only one use case, so is Xft.dpi-first deliberate to support standalone apps with the simple case, and if so, should embedded windows default the other way, prioritising Host scale?

Very happy to submit a PR for this too, if it would be welcomed. I'd just need to know if aligning with CLAP is preferred, or backwards compatibility and a new setter is preferred...

cheers