diff options
| author | Dudemanguy <random342@airmail.cc> | 2024-03-04 09:42:15 -0600 |
|---|---|---|
| committer | sfan5 <sfan5@live.de> | 2024-03-04 22:42:46 +0100 |
| commit | 781f78fb3a0457aea8084f94feeeb69978a02a71 (patch) | |
| tree | 6b8e52974ae0f82d3d4182a1e6db63d37978bcf7 /video/out/wayland_common.h | |
| parent | 9ac791c329aa967d6034da1543e03c777b09f4ef (diff) | |
| download | mpv-781f78fb3a0457aea8084f94feeeb69978a02a71.tar.bz2 mpv-781f78fb3a0457aea8084f94feeeb69978a02a71.tar.xz | |
wayland: guess the first hidpi frame better
It's been a longstanding issue in wayland* that the first frame on a
hidpi screen will have wrong scaling. A well behaved client immediately
corrects this, but it's noticeable and also can affect window placement
due to the way resizng works. Preferred scale from the fractional
protocol and preferred buffer scale can actually solve this problem. It
depends on compositors mostly, but one could simply send the event
before the client maps its surface so it knows what the correct scale is
in the first place. I'm not sure if any compositors currently behave
like this (sway seems to still require the client to render before
sending any scaling information at least), but it makes to sense to
account for this possibility.
*: https://gitlab.freedesktop.org/wayland/wayland/-/issues/133
Diffstat (limited to 'video/out/wayland_common.h')
| -rw-r--r-- | video/out/wayland_common.h | 1 |
1 files changed, 1 insertions, 0 deletions
diff --git a/video/out/wayland_common.h b/video/out/wayland_common.h index 721d4fb2eb..3e8530eaff 100644 --- a/video/out/wayland_common.h +++ b/video/out/wayland_common.h @@ -75,6 +75,7 @@ struct vo_wayland_state { bool hidden; bool initial_size_hint; bool locked_size; + bool scale_configured; bool state_change; bool tiled; bool toplevel_configured; |