mpv icon indicating copy to clipboard operation
mpv copied to clipboard

mpv detects the wrong resolutin with wayland session if the session is using fractional zoom.

Open rezad1393 opened this issue 2 years ago • 17 comments

Important Information

Provide following Information:

  • mpv version
  • mpv 0.34.0
  • Linux Distribution and Version
  • archlinux
  • Source of the mpv binary
  • archlinux repos
  • Window Manager and version
  • kde plasma with wayland
  • GPU driver and version
  • amd apu Lucienne
  • Possible screenshot or video of visual glitches

Reproduction steps

I have removed xorg to debug a separate issue I have with my ram usage. so I use wayland for now with plasma kde session. and in both xorg and plasma I have set my scaling to 150% from setting panel ,monitor tab. in xorg and wayland everything is zoomed so I can actually read on my small 14inch 1080p laptop. but it seems that they use different ways for this zoom. in xorg I still have the 1080 resolution and just the it is zoomed. so if I open a1080p movie in mpv and fullscreen it say native resolution is 1080 and scaled one the same. but in wayland the resolution and laptop also changes with the zoom to 720p.

so far this a wayland/xorg difference/issue but the bug with mpv is that when I open a movie with mpv it thinks my laptop resolution is 1440p. so in the video info at fullscreen for scaled one it says 2560x1440

rezad1393 avatar Nov 13 '21 23:11 rezad1393

I'm not sure I understand. Is your laptop actually 2560x1440 or not? If so, that's what should be reported at fullscreen regardless of whatever your scaling/dpi settings are. As an aside, clients in wayland can't do non-integer scaling so the 150% setting is completely done compositor side by plasma.

Dudemanguy avatar Nov 14 '21 03:11 Dudemanguy

I'm not sure I understand. Is your laptop actually 2560x1440 or not? If so, that's what should be reported at fullscreen regardless of whatever your scaling/dpi settings are. As an aside, clients in wayland can't do non-integer scaling so the 150% setting is completely down compositor side by plasma.

sorry I seems to have forgotten to type that. my laptop is a 14inch 1080p and text is too small with default kde plasma install. that is the whole reason for zoom/scale.

also I dont understatnd this part (not being fluent in english) " completely down compositor side by plasma." the scaling seems to work for most app. but somehow mpv sees my resolution as 1440 when every other app sees it as 720p.

btw I dont know how kde plasma kwin window manager works and monitor scaling in xorg doesn't reduce the resolution but wayland does. I dont know which is the correct behavior or even if there is such a thing as correct one here. but personally I dont want to lose my resolution I just want to be able to read text on laptop :)

I think my issue that I need to zoom for is that linux is very buggy and immature vs windows in handing ppi for screens (hdr and so on are also other issues that other systems ether solved or are solving, I hope red hat solves that)

or maybe this is just kde fault but I tested with gnome too and text in firefox is very bad there too. I dont have a windows to see if windows handle this better but from what I see on other people computers it seems to be a solved issue.

now after than rant, I type my issue one more time. if I use scaling from plasma setting in kde set to 150%, mpv detects my resolution as going up from 1080 to 1440 instead of going down to 720. so when I full-screen a 16x9 video the scaled resolution is shown as 2560x1440.

rezad1393 avatar Nov 14 '21 03:11 rezad1393

Can you post a log file?

Dudemanguy avatar Nov 14 '21 03:11 Dudemanguy

Can you post a log file?

not right now. I am back on X and have some work to do.

rezad1393 avatar Nov 14 '21 03:11 rezad1393

Very late here, but I understand what this issue is after reading it again. It's just crappy wayland fractional scaling behavior. What's happening is that mpv renders above your laptop's resolution (based on information from the compositor) and then the compositor downscales it to the "correct" one. This isn't fixable since wayland has no real fractional scaling atm. We would need this protocol.

Dudemanguy avatar Apr 11 '22 03:04 Dudemanguy

yeah. it seems to be that. but nobody else notices that global scale used in kde or gnome when using in wayland, lowers the resolution?

a command that I found helpful is wayland-info. that shows that way land sees a physical 1080p screen but a 72op logical one is used.

rezad1393 avatar Apr 11 '22 07:04 rezad1393

I was searching for wayland scaling issue and found this. Haven't actually noticed it for mpv but apparently it's a XWayland wide issue that affects many applications. See https://bugs.kde.org/show_bug.cgi?id=389191

davispuh avatar Apr 11 '22 21:04 davispuh

That's a scaling issue, but a totally different one. It's not related.

Dudemanguy avatar Apr 11 '22 21:04 Dudemanguy

It is same thing, scaling in Wayland breaks X11 apps. Same root cause - different ways it manifests (blurry apps, wrong resolution etc). This is https://youtu.be/AS9H8QrV5Ig what it does for me :D

davispuh avatar Apr 11 '22 23:04 davispuh

Please don't confuse this issue with xwayland problems. Xwayland has no hidpi support which leads to various scaling issues. That is not the issue in this ticket. mpv is a native wayland client that supports hidpi. The problem is that the wayland protocol does not support fractional scaling.

Dudemanguy avatar Apr 12 '22 02:04 Dudemanguy

Ohh, indeed my bad, I thought mpv isn't using Wayland, because the effect is similar in both cases - wrong resolution for apps.

I just tried mpv with 150% scaling and indeed it thinks it has bigger resolution. scale150

When scaling to 200% then it works correctly

scale200

So this means the way how fractional scaling is implemented in Wayland is not suitable for many applications.

davispuh avatar Apr 12 '22 03:04 davispuh

Yeah I would highly recommend using only integer scaling with mpv because of this. For some applications, this behavior may not be that big of a deal, but for mpv it is awful. It's a great way to nuke your performance.

Dudemanguy avatar Apr 12 '22 03:04 Dudemanguy

when I reported this issues I didnt know it was a wayland issue. and the wayland issue is way more upstream (not in software way but in product line way) that is needs to be fixed first for anything else related to be fix after.

even when I reported it here https://bugs.kde.org/show_bug.cgi?id=452261 just like here with @davispuh , the answer I got was , incorrectly, related to xwayland. but this is not correct. I can remove the whole x11 and even neuter the xwayland (cause it is a dependency of wayland I cant remove it) and still be able to run a plasma kde desktop and run mpv and see this exact issue. so it is NOT a xwayland issue. that is separate.

right now I even have no way of confidently knowing what my whole desktop runs at when using 150% zoom in kde with wayland, because every app that I use seems to use a 720p screen in that scenario, when my physical screen is 1080p. the wayland-info app give a good summery but I am not sure how to interpret the 720p scaled vs 1080p screen in that command, as if how to see what resolution my whole screen (which other app run inside that) sees. as you know even if this behavior can be used to zoom and show bigger UI element (on my small screen with somewhat hiDpi ,158dpi) I still think this behavior is wrong because there is no way to match 720p virtual screen that an app sees with 1080p physical screen on the laptop, so it means blur and anti-aliasing ,Which by default lower the crispness even if it is not that obvious, unlike using firefox in xwayland mode.

as I explained on that bug try to view a picture(not video) that has the same pixels as your physical screen in this zoomed wayland mode and tell the program to show the picture in 100% zoom, you see it stretches beyond screen because that app is getting a, for my case, virtual 720p screen and so it stretches the 1080p beyond my screen and what ever software magic it is used with wayland (ignore xwayland for now) then is no way in God's green earth that a 1080 picture can be matched to a 720 virtual screen pixels then matched that to 1080 physical screen. this causes twice the quality reduction V.S. just X11 matching one to one a 1080 picture to 1080.

and even if you dont notice it that much because of ,my-not-20-20-eye-sight or software magic/fu..kery, this still is a physic/math issue of matching a 1080 dots to 720 dots and again 720 to 1080 that cant happen.

so basically we need for wayland to fix this and fix this correctly and stabilize before we try anything (if it is not fixed automatically in mpv because of wayland fix).

I think we should keep this issue open and refer others that get this issue to it. so that others don't get confused and have all the available data we gathered in one place for this issue.

rezad1393 avatar Apr 12 '22 08:04 rezad1393

this seems to affect all wayland wayland app views in weird ways.

for example I have firefox on wayland and and in kde setting I have set my 1080p screen to 150% scaling so I can test and websites see a 720p screen,and also I have a addon that when I open a picture directly it shows in original resolution and also the resolution that it is displayed in and in full screen it shows the max view resolution for picture as 720p . so when I change firefox window size the resolution for that image changes but the max that addon sees is a 720p screen.

now the weird part: when I use the screenshot option in firefox right click menu and use the "save visible" when firefox is in fullscreen then firefox saves a 1440p screenshot from that same image.

so the image and firefox web sees a 720p but firefox process uses a 1440 graphic output.

this is really bad for performance.

remember this is not a video I am talking about.

rezad1393 avatar Aug 28 '22 13:08 rezad1393

For reference, this Wayland protocol discussion describes this exact issue: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/47

Since the client renders into a larger-than-native buffer there is a significant performance overhead, which is especially noticeable in graphics intensive applications such as games. Example: on a 4K (3840 × 2160) display with an optimal scale factor of 1.5 a game might render at 5K (5120 × 2880) resolution requiring 78% more pixels than necessary to be rendered.

Looks like a workaround right now is to implement wl_viewporter to get it to render without going through a larger-than-native buffer but it has the downside of a potential off-by-one error.

Viewporter is the best way to workaround the lack of proper fractional scaling right now, but it's IMO a protocol abuse and would require overengineering if we take 1:1 pixel alignment into account. [source]

jkcdarunday avatar Aug 28 '22 15:08 jkcdarunday

Using viewporter alone is not really acceptable because that means the compositor does all the scaling which defeats one of the purposes of mpv. From the client side, there is no way to tell the difference between a normal integer scale (which works correctly) and a fractional scale so you would just be making it strictly worse for anyone on the former. The leading fractional scale proposal involves using viewporter though so I'll have to hook that up in the future anyway if it ever gets merged upstream.

Dudemanguy avatar Aug 28 '22 15:08 Dudemanguy

I knew about that. I didnt know that an app would use both 720 and 1440 together. now I checked about:support in firefox and I see Display0 2560x1440@60Hz scales:2.000000|2.000000

so firefox only sees that 1440 but somehow shows the 720p to webpages to achieve the zoom. maybe it uses a workaround.

rezad1393 avatar Aug 28 '22 15:08 rezad1393