Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#359 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
14/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
desktop

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Rust
Estrellas
387
Forks
128
Merge medio
3 d 2 h
PR fusionados (30 d)
15

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de RustAudio/baseview

Todos los issues de RustAudio/baseview

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.