Host Scaling not reflected in plugin window scaling on X11, maybe on Win32
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
調査の方向性
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時間
- マージ済み PR（30日）
- 15
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
RustAudio/baseview のほかの issue
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
RustAudio/baseview#343 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
RustAudio/baseview#342 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
RustAudio/baseview の issue をすべて見る
似ている issue
-
area:docs documentation good first issue priority:medium
難易度 1/5 1時間未満 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信
-
feature
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
calagopus/panel#285 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
[Bug]: streamed Responses API flex_unavailable error maps to 500 InternalServerError instead of 429オープンllm translation
難易度 2/5 1時間未満 初心者へのやさしさ 85/100
BerriAI/litellm#49736 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
question
難易度 1/5 1時間未満 初心者へのやさしさ 72/100
メンテナーはふだん 1 日以内に返信
-
autoindex tests: denied loopback bind shows only PermissionDenied (255 failures), not the causeオープンfield-report
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
メンテナーはふだん 1 日以内に返信