Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#359 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
14/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
desktop

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

It is documented that way:

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

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 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

Lingua principale
Rust
Stelle
387
Fork
128
Merge medio
3g 2h
PR unite (30g)
15

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di RustAudio/baseview

Tutte le issue di RustAudio/baseview

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.