sway
sway copied to clipboard
wxWidgets gets wrong rendering area on scaled high DPI monitors
Please fill out the following:
-
Sway Version: 1.8.1
-
Debug Log:
- omitted due to failure to reproduce the intermittent issue, interruption to my desktop usage and a previous failed attempt to collect a log
-
Configuration File:
- I believe it should reproduce on a default config with additional config like this (from my config verbatim)
output "Samsung Electric Company LU28R55 HNMW104971" position 1200 188 res 3840x2160 output "Samsung Electric Company LU28R55 HNMW104971" scale 1.398438 output "Samsung Electric Company LU28R55 HNMW104969" position 3945 188 res 3840x2160 output "Samsung Electric Company LU28R55 HNMW104969" scale 1.398438 output "Eizo Nanao Corporation EV2436W 65118044" transform 90 output "Eizo Nanao Corporation EV2436W 65118044" position 0 0
- I believe it should reproduce on a default config with additional config like this (from my config verbatim)
-
Stack Trace:
- no crashing involved
-
Description:
- KiCad (and wxWidgets) recently started to get Wayland support working, in testing these changes i found an issue which i assume the KiCad contributor could not reproduce on Gnome, because they suggested i open an issue here
- screenshot copied from that issue showing the main KiCad window in the background, and a floating sub-program window on top, showing the rendered area exceeding the window decoration
- i believe the issue is that on a scaled DPI monitor, KiCad receives the wrong area to render into (or the wrong window size?)
-
the wxWidgets
cube
sample exhibits the same issue - while i've been able to trigger apparently semi-persistent correct behaviour by unplugging and replugging some monitors, it also seems to spontaneously go away and i'm unable to making capturing debug information problematic
- this is on KiCad master on wxWidgets 3.2.3 on Sway 1.8.1 on NixOS unstable