[Wayland] quick vertical resizing reverts the window dimensions to before the resize.

[ToxicMushroom]

mpv Information

mpv v0.39.0 Copyright © 2000-2024 mpv/MPlayer/mplayer2 projects
 built on Nov 27 2024 18:31:26
libplacebo version: v7.349.0
FFmpeg version: n7.1
FFmpeg library versions:
   libavcodec      61.19.100
   libavdevice     61.3.100
   libavfilter     10.4.100
   libavformat     61.7.100
   libavutil       59.39.100
   libswresample   5.3.100
   libswscale      8.3.100

Other Information

- Linux version: Arch Linux
- Kernel Version: Linux karamba2000 6.12.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 27 Dec 2024 14:24:37 +0000 x86_64 GNU/Linux
- GPU Model: [AMD/ATI] Navi 23 [Radeon RX 6650 XT / 6700S / 6800S] [1002:73ef] (rev c1)
- Mesa/GPU Driver Version: Mesa 24.3.2-arch1.1
- Window Manager and Version: 
  - KDE Plasma: 6.2.4
  - Niri: 0.1.10 (v0.1.10-154-g4741ab2e)
- Source of mpv: arch extra repo
- Latest known working version: /
- Issue started after the following happened:
  I started testing the new Niri floating mode (see https://github.com/YaLTeR/niri/issues/908).

Reproduction Steps

1. mpv --no-config somevideo.mp4
2. perform a quick (as in mouse speed) vertical resize

Expected Behavior

mpv keeps the dimensions after the resize regardless of how fast I resize.

Actual Behavior

mpv reverts to its initial dimensions after the compositor already showed mpv at the requested resized dimensions.

(On Niri the video also jumps position but on KDE it does not. Maybe @YaLTeR knows why)

niri-mpv-interactive-resize-nyn-jumping.mp4

I can attach a kde recording too if requested.

Log File

output.txt

Sample Files

wayland-resize-sample.zip

I carefully read all instruction and confirm that I did the following:

• I tested with the latest mpv version to validate that the issue is not already fixed.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[YaLTeR]

My semi-blind guess (haven't looked at the log myself) is that there might be some race in mpv between one part of the code committing a new video frame with the previous size, another part of the code trying to change the size, and ack_configure being delivered incorrectly. I.e. if mpv sends ack_configure right away instead of together with the corresponding surface commit, this kind of issue can happen.

(On Niri the video also jumps position but on KDE it does not. Maybe @YaLTeR knows why)

This is compositor-specific logic that tries to keep the opposite window edge in place during resizing; minor differences in handling can result in this. But generally if the client is well behaved everything should work without unexpected movement.

[Dudemanguy]

This doesn't happen if you use --no-keepaspect-window or --no-keepaspect right? It's because of the way we're trying to preserve the window size and aspect ratio. Not sure what the fix would be.

[ToxicMushroom]

This happens too with --no-keepaspect-window but less reliably (maybe 10-20%), can repro for vertical, horizontal and diagonal.

[Dudemanguy]

Ah maybe I just didn't try hard enough. But it doesn't happen with --no-keepaspect right? Just to make sure I'm still on the right track here.

[ToxicMushroom]

No it also happens with --no-keepaspect :/

[Dudemanguy]

I thought I was reproducing the issue in sway but perhaps I was seeing something else? I guess I'll try niri later.