mpv with fifo presentation lags terminally when resizing a paused video or image

[mahkoh]

mpv Information

mpv v0.40.0-dirty Copyright © 2000-2025 mpv/MPlayer/mplayer2 projects
 built on Sep 24 2025 17:56:15
libplacebo version: v7.351.0
FFmpeg version: n8.0 (runtime n8.0.1)
FFmpeg library versions:
   libavcodec      62.11.100
   libavdevice     62.1.100
   libavfilter     11.4.100
   libavformat     62.3.100
   libavutil       60.8.100
   libswresample   6.1.100
   libswscale      9.1.100

Other Information

- Linux version: not relevant
- Kernel Version: not relevant
- GPU Model: AMD RX 6600
- Mesa/GPU Driver Version: mesa 25.2.7
- Window Manager and Version: Jay 
- Source of mpv: Both current arch version and master are affected
- Latest known working version: none
- Issue started after the following happened: probably after mpv became aware of wp-fifo-v1 and started using fifo on wayland

Reproduction Steps

• Play any video on a compositor that supports wp-fifo-v1 with no particular command line arguments. I have tested KDE and Jay.
• Pause the video
• Resize the window

Expected Behavior

The window resizes smoothly

Actual Behavior

The resizing lags unbearably behind the mouse. On Jay, the connection is terminated soon afterwards with the following error:

An error occurred while processing a request: Could not process a wl_surface#6.commit request: The client has too many pending commits

This is because Jay has an upper limit of 128 unapplied commits per client to prevent resource exhaustion.

This issue does not happen while the video is playing. Even so, wp-fifo-v1 is fundamentally broken for applications that want to support smooth resizing. See https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/495.

mpv seems to have perfectly functional mailbox support which it should always prefer on wayland unless the user explicitly opts into fifo. You can currently invoke it manually with --vulkan-swap-mode=mailbox and the issue goes away.

Log File

output.txt

Sample Files

No response

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.

[llyyr]

mpv seems to have perfectly functional mailbox support which it should always prefer on wayland unless the user explicitly opts into fifo.

mailbox support is a bit of a hack, though. I thought fifo support would do something smarter than this https://github.com/mpv-player/mpv/blob/master/video/out/wayland_common.c#L4647-L4700

[mahkoh]

I don't think anything other than fixed-rate fullscreen applications like games was really considered during wp-fifo-v1 development. At least I don't remember anything like that.

[llyyr]

Isn't this something to fix on the Wayland/Mesa side then? Of course mpv can do the Right Thing^TM here, but you can't really expect every single application to do the same. Anything that picks FIFO via Vulkan is going to run into this problem

[mahkoh]

Luckily most applications don't. Most desktop-style applications are better off with mailbox and that's what they seem to be using. But yes, shit's fucked and the only reason that it's not more visible is that most fifo users are games that are almost always fullscreen.

It might be worth investigating why paused videos behave so much worse than playing videos.

[llyyr]

It might be worth investigating why paused videos behave so much worse than playing videos.

May be a duplicate of #16744

Resizing seems be sluggish when there's no video playing to force updates, will need to investigate why. Though this seems to be the case even with opengl, the only common denominator is the use of the wayland backend

[mahkoh]

Yes, that is the same issue. However, I think contrary to the analysis in there the issue is caused by fifo.

[atrxia1]

the only common denominator is the use of the wayland backend

I can replicate this exact issue on Windows with --d3d11-flip=yes, but not --d3d11-flip=no. But I never bothered reporting it because I wasn't sure if this was a compositing issue or mpv issue.

[mahkoh]

The issue seems to be that, while playing a video, mpv is busy outside of the wayland code a lot of the time. This causes a singe wl_display_dispatch_pending call to dispatch a great many resize events. This acts as a sort of debounce where things throttle themselves. So if you have 1000 resize events, mpv might only act on every 100th of them.

On the other hand, when the video is paused, mpv is much more responsive and dispatches events immediately. So if you have 1000 resize events, mpv actually resizes the swapchain 1000 times. This causes the compositor-side fifo queue to fill up immediately.

This does not seem intentional so mpv only gets lucky when it's playing a video.

[mahkoh]

I have looked at what vulkan specifies and it does not say anything about this situation. That is, it is both possible for the FIFO queue to grow indefinitely if mpv re-creates the swapchain an indefinite number of times, and it is possible for the FIFO queue to get flushed when the swapchain is recreated. So far I have not found any information about how Vulkan drivers behave on windows in this situation.

For compatibility with all possible implementations, mpv must throttle itself after recreating the swapchain when using FIFO.

[llyyr]

Doesn't the fifo protocol allow clearing the barrier early if needed?

The compositor may clear the condition early if it must do so to ensure client forward progress assumptions.

I believe it would make sense for the WSI or compositor to clear fifo barriers during resize operations no?

[mahkoh]

There is no way for the client to communicate this intent at the moment. That is what https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/495 is about. The WSI is unable to do anything about this.

The compositor might be able to get clever with it but I have not looked into this.

[llyyr]

There is no way for the client to communicate this intent at the moment

Correct me if I'm wrong, but isn't there a way for WSI to detect this? It already returns VK_SUBOPTIMAL_KHR if the window gets resized but the client doesn't commit the appropriate sized texture. WSI knows when the swapchain is recreated with different surface size which could be used to clear fifo barriers.

[mahkoh]

It already returns VK_SUBOPTIMAL_KHR if the window gets resized but the client doesn't commit the appropriate sized texture.

It doesn't. The WSI has no way to know if the window has been resized. The only time the wayland WSI returns suboptimal is if the window goes fullscreen and the buffers need to be recreated to enable direct scanout.

WSI knows when the swapchain is recreated with different surface size which could be used to clear fifo barriers.

The WSI cannot clear fifo barriers.