Host Scaling not reflected in plugin window scaling on X11, maybe on Win32
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
研究方向
The scale logic lives in src/platform/x11/sizing.rs (scale_factor and handle_host_suggest_scale_factor, where Xft.dpi takes precedence over the host value), with the fallback documented in src/window.rs and src/settings.rs, and the Win32 path in src/platform/win/dpi.rs. Start by reading how suggest_fallback_scale_factor reports its result, since the issue asks whether a suggestion was applied. Done would need a maintainer-agreed API design for host-priority scaling and a decision on backward compatibility, so this should be discussed before any code is written.
由索引模型根據 Issue 內容生成。
描述
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_factorL111-L125 - It returns early when Xft.dpi exists.
It is documented that way:
-
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] (https://github.com/RustAudio/baseview/blob/4c79df39b41a9868c9685b3cde369b79f017b1a1/src/platform/x11/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 answerset_scaletruthfully - (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
- 主要語言
- Rust
- 星號
- 387
- 分支
- 128
- 平均合併
- 3 天 2 小時
- 30 天內合併 PR
- 15
環境準備
這個專案沒有提供開發容器、Dockerfile 或貢獻指南，環境需要你自己搭建：先看它的 README，通用步驟見我們的新手貢獻指南。
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
RustAudio/baseview 的其他 Issue
-
難度 5/5 一週以上 新手友好度 25/100
維護者通常 1 天內回覆
-
enhancement
難度 5/5 一週以上 新手友好度 25/100
維護者通常 1 天內回覆
-
難度 5/5 一週以上 新手友好度 25/100
維護者通常 1 天內回覆
-
難度 5/5 一週以上 新手友好度 35/100
RustAudio/baseview#343 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 5/5 一週以上 新手友好度 35/100
RustAudio/baseview#342 · 1 個 reaction ·
維護者通常 1 天內回覆
查看 RustAudio/baseview 的全部 Issue
相似的 Issue
-
needs triage
難度 2/5 1-3 小時 新手友好度 65/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 65/100
-
難度 2/5 1-3 小時 新手友好度 72/100
mozilla-services/syncstorage-rs#2715 ·
維護者通常 1 天內回覆
-
難度 1/5 1 小時以內 新手友好度 70/100
-
documentation
難度 1/5 1 小時以內 新手友好度 82/100
physicsdolphin/nv-uefi-unlocker#53 · 4 個 reaction ·
維護者通常 1 天內回覆