You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With either --vo=opengl:backend=wayland or --vo=wayland, mpv doesn’t honor the size request from the compositor if the video’s aspect ratio doesn’t match the output’s aspect ratio. This is actually allowed by the wl_shell protocol, but results in poor performances in Weston (since it will then composite mpv’s surface alongside black surfaces to make up for the missing space, doing a non-required pass through GLES again), or bad rendering in gnome-shell (see #2657, which likely shares Weston’s behaviour to prevent the primary plane from being used).
Here is an example of WAYLAND_DEBUG=client log where I’m playing a 1920×1038 video on a 1920×1080 output:
linkmauve
changed the title
[wayland] In fullscreen, always create a buffer of the size requested by the compositor
In fullscreen, always create a buffer of the size requested by the compositor
Apr 3, 2016
When we receive the wl_shell_surface::configure event, it makes sense
to respect the aspect ratio of the video in windowed mode, but in
fullscreen it forces compositing and wastes resources (until atomic
modesetting is available everywhere and we can stop having
desynchronised planes).
Weston mitigates a resolution mismatch by creating black surfaces and
compositing them around the fullscreen surface, placed at the middle,
while GNOME puts it at the top-left and leaves the rest of the desktop
composited below, both of them producing a subpar experience.
Fixesmpv-player#3021, mpv-player#2657.
With either
--vo=opengl:backend=wayland
or--vo=wayland
, mpv doesn’t honor the size request from the compositor if the video’s aspect ratio doesn’t match the output’s aspect ratio. This is actually allowed by the wl_shell protocol, but results in poor performances in Weston (since it will then composite mpv’s surface alongside black surfaces to make up for the missing space, doing a non-required pass through GLES again), or bad rendering in gnome-shell (see #2657, which likely shares Weston’s behaviour to prevent the primary plane from being used).Here is an example of
WAYLAND_DEBUG=client
log where I’m playing a 1920×1038 video on a 1920×1080 output:The text was updated successfully, but these errors were encountered: