Window resize has a max limit?

d3x0r commented 4 years ago

Important Information

Provide following Information:

mpv version : 1.0.32.0-1
Linux Distribution and Version : Arch Latest (updated last night)
Source of the mpv binary : prebuilt image from Arch package manager
If known which version of mpv introduced the problem : Unknown
Window Manager and version : weston/KWin/Plasma (all latest available)
GPU driver and version : amdgpu
Possible screenshot or video of visual glitches : n/a

Reproduction steps

Start playing a video. The window starts at the size of the video; I have 2 4k monitors, and most videos I get are like 360p... so I usually resize the window. Grabbing the title bar towards the top of the window allows me to resize the window, however, once I reach about 2x the size of the current (unsized) window, the sizing stops, and snaps back to the starting size. So to stretch most videos to a confortable size I have to click, drag bigger, move the mouse back a bit since I will inevitably stretch it larger than 2x to start, and eventually let go, and have to reclick the sizing and stretch it again... depending on how close to 2x I got in the irst place I can usally get a good display size, but often I only get to like 1.5x, so the second resize will still end up moving bigger than 2x the new size and have to re-adjust the mouse back to where it is resizing...

Expected behavior

As long as the mouse is clicked and held, the resizing should work, without some sort of limit .

and basically all the resizes should be greater then the prior...

[  15.922][v][vo/gpu/wayland] Resizing due to xdg from 1841x1036 to 1838x1034

Actual behavior

I don't see anything in the log about why the size drops back immediately to the small size.

[  16.169][v][vo/gpu/wayland] Resizing due to xdg from 1838x1034 to 1848x1040
[  16.177][v][vo/gpu/wayland] Resizing due to xdg from 1848x1040 to 1045x587

Log file

mpv.log

Sample files

I don't know that any specific video is required; it happens on all that I have; it might require a monitor big enough to stretch videos a couple times...

Dudemanguy commented 4 years ago

I can't reproduce here (wayland/waylandvk with weston or sway) on my 4k monitor. Some blind guesses, but maybe check a few things real quick.

Does it happen if you only have one monitor plugged in?
Does it happen in vulkan?
Does it happen in xorg?

d3x0r commented 4 years ago

I can't reproduce here (wayland/waylandvk with weston or sway) on my 4k monitor. Some blind guesses, but maybe check a few things real quick.

Does it happen if you only have one monitor plugged in?

(will try and update in a bit)

Does it happen in vulkan?

does do it with -vo=wlshm mpv.log

[vo/wlshm/wayland] Resizing due to xdg from 1121x631 to 1130x636

am not sure how to enable vulkan ... --gpu-api=vulkan wouldn't seem to be an output

does NOT do it with --vo=x11 mpv.log

Does it happen in xorg?

I can't get xorg to start...

Dudemanguy commented 4 years ago

On Arch you'll need vulkan-radeon installed for the vulkan context. Although I guess judging that it happens in wlshm (totally forgot about that; thanks for testing that one), I assume you'll probably have the same issue there.

I can't get xorg to start...

You can try it with xwayland (--gpu-context=x11egl). That should work unless you went out of your way to remove xorg completely (unlikely). Anyways, it's almost certainly a wayland issue on our end. Going to assume this has something to do with multimonitor although I don't remember this happening when I tested it way back when.

bitraid commented 4 years ago

I've noticed that on wayland/sway (but not on xwayland), when a floating mpv window is resized with Alt-0, switching to another window resets the mpv window size. There are also problems with with rotate and autofit: see https://github.com/swaywm/sway/issues/4094, which should be the same root cause as #6653, but it's not fixed by #6978.

d3x0r commented 4 years ago

--gpu-context=x11egl does not have issues resizing. I had vulkan-radeon installed... vkcube shows a spinning cube. Unplugged a monitor; KWin moved most things to the remaining montior, and reset to a 2x scaling factor; but the behavior was still the same. Ending KWin/plasma and restarting it has the same problem with the default option (first log file) which appears to be OpenGL... (EGL? for window management? which is the same for vulkan?)
I did notice that the refresh rate is set as 30Hz... This is an AMD1605B

AMD Ryzen™ Embedded V1605B with Radeon™ Vega 8 Graphics

item	val
# of CPU Cores	4
# of Threads	8
CPU Max Freq.	Up to 3.6GHz
CPU Base Freq.	2.0GHz
TDP	12-25W
GPU Brand	AMD Radeon™ Vega 8 Graphics
GPU Max	1100 MHz
GPU CU	8
# Displays	4
Max Resolution (for single display)	4096x2160
Display Interfaces	up to 4x HDMI 2.0b or 4x DP 1.4
HW Video Encode / Decode	up to 4K @ 60Hz



Probably all irrelevant...

ghost commented 4 years ago

Sounds more like Wayland vs. x11?

Dudemanguy commented 4 years ago

Yeah don't worry about vulkan. That's a totally separate thing.

Does this happen to you in single monitor with Weston? I've definitely resized just fine in Plasma before.

d3x0r commented 4 years ago

Yes, starting weston with a single monitor behaves the same way (dropping the resize drag)

Dudemanguy commented 4 years ago

I can't reproduce it here. In one go, I can resize a video to much larger than 2x the size. No idea how this is happening to you.

FWIW: I can reproduce the window-scale thing so maybe that's related.

Dudemanguy commented 4 years ago

Try #7432? I don't think it will fix this issue, but maybe we got lucky.

bitraid commented 4 years ago

Try #7432? I don't think it will fix this issue, but maybe we got lucky.

For me, it didn't fix window-scale, either. Using sway version 1.4-ffbf10d0 (Jan 31 2020, branch 'master')

Dudemanguy commented 4 years ago

Hmm, it looks like VO_EVENT_RESIZE doesn't send a configure event to the compositor for some reason. That might be the source of the problem.

Dudemanguy commented 4 years ago

Ah, I had misunderstood how xdg_configure.toplevel was supposed to work. The compositor isn't supposed to send a configure event there. Okay, I know the right way to do this now (although unsure if this will actually fix OP's issue).

Dudemanguy commented 4 years ago

Okay, I updated #7432. I think that should fix the window-scale thing as well as some other annoying window resize issues I stumbled upon. Still not sure if this fixes @d3x0r's issue, but assuming everything else is good, I'll merge it anyway.

bitraid commented 4 years ago

window-scale fixed! Any idea why add video-rotate causes problems when autofit/autofit-larger is set?

Dudemanguy commented 4 years ago

Not sure what you mean. I just tried it and it seemed fine. Open up a new issue for it though.

d3x0r commented 4 years ago

Sorry I haven't been able to test it until now. I see that the changes have been merged, and I just built mpv master and it still does the same thing; would you like a log? If you make a private forked sort of branch I can test from that also...

edit: I did notice a similar sizing flicker iwth terminator a python based(?) terminal program. I was looking at a log....

[vo/gpu/wayland] Resizing due to xdg from 1478x617 to 1516x633
[vo/gpu/wayland] Handling resize on the egl side
[vo/gpu] Resize: 1516x633
[vo/gpu] Window size: 1516x633 (Borders: l=0 t=0 r=0 b=0)
[vo/gpu] Video source: 640x268 (268:267)
[vo/gpu] Video display: (0, 0) 640x268 -> (0, 0) 1516x632
[vo/gpu] Video scale: 2.368750/2.358209
[vo/gpu] OSD borders: l=0 t=0 r=0 b=1
[vo/gpu] Video borders: l=0 t=0 r=0 b=1
[vo/gpu] Reported display depth: 10
[osc] osc_init 
[cplayer] Run command: change-list, flags=64, args=["shared-script-properties", "append", "osc-margins=0.000000,0.000000,0.000000,0.000000"]
[cplayer] Set property: shared-script-properties -> 1
[vo/gpu/wayland] Resizing due to xdg from 1516x633 to 642x268
[vo/gpu/wayland] Handling resize on the egl side
[vo/gpu] Resize: 642x268
[vo/gpu] Window size: 642x268 (Borders: l=0 t=0 r=0 b=0)
[vo/gpu] Video source: 640x268 (268:267)
[vo/gpu] Video display: (0, 0) 640x268 -> (0, 0) 642x268
[vo/gpu] Video scale: 1.003125/1.000000
[vo/gpu] OSD borders: l=0 t=0 r=0 b=0
[vo/gpu] Video borders: l=0 t=0 r=0 b=0
[vo/gpu] Reported display depth: 10
[osc] osc_init

is the last resize, then it's just drug up the screen... the window moves(just changes position) while dragging ,then I move the window back down to where it resizes, and the lower left corner drops to the original position... so while it ends up dragging, none of those are logged with -v -v

Dudemanguy commented 4 years ago

Hmm well if you got the resizing issue to happen with another client, I'm starting to think something else is the issue here. Presumably, terminator doesn't do anything particularly complicated in terms of rendering and it does use vte3 which does have native wayland support.

Wild guess here but since you use a 4k monitor do you use fractional scaling on your compositor?

d3x0r commented 4 years ago

Weston didn't have scaling from what I saw. kWin defaults to 2x scaling, which I reset to 1.0 It's not Exactly the same behavior.... but it does seem to have a defaulting issue; it might be that it's using a different font from the system font, so it resizes twice somehow.... it (edit: Usually) seems to end in the right place.... but there's also more places to resize, and it's not always aspect-scaled resizing...

Dudemanguy commented 4 years ago

I think somehow the compositor is returning very bad width and height arguments in the toplevel listener to mpv. There's scenarios where those values can be wrong, but they should be predictable for the most part. And certainly, it shouldn't randomly go back to a small size in the middle of a resize. mpv might just happen to be a particularly easy client for you to produce this bug since we're constantly drawing frames. As for why this happens, this is beyond me. Across multiple wayland clients in multiple compositors suggests something relatively low level unfortunately (driver or something).

Edit: Is it easier or harder to reproduce the resize bug while the video is paused?

d3x0r commented 4 years ago

Edit: Is it easier or harder to reproduce the resize bug while the video is paused?

Pause/Play doesn't have any difference.

Dudemanguy commented 4 years ago

@d3x0r: Does the problem still occur with #7457?

I don't expect it to fix it, but it does change the resizing logic.

d3x0r commented 4 years ago

Uhmm... that's a leading question. It does not work better. Now, when I grab the top of the window to resize, it just drags the window up in the same size. Edit: The resize messages do not show in the log. The only wayland message is enabling idle inhibitor. -v -v ? If I grab the lower right corner with a proper 2 way resize, it doesn't resize... It stays in the same sport (sort of) the frame shifts within the frame, and at one point it sits there just togging between two frames; (no sound ATM, so I don't know what that's doing meanwhile)

Dudemanguy commented 4 years ago

Now, when I grab the top of the window to resize, it just drags the window up in the same size.

Oh yeah, this part on Plasma I can reproduce. It looks like the compositor doesn't let mpv resize that way. Not too concerned about that honestly since the current resizing logic sucks and Plasma is known to have some geometry issues anyway. The rest sounds pretty bad though. I didn't expect it to get worse. Mind uploading a full log?

d3x0r commented 4 years ago

mpv.log

Dudemanguy commented 4 years ago

Resizing due to xdg from 641x360 to 0x0

Yeah, something is somehow wrong with calculating the width/height coordinates for resizing. If you don't mind, could you test this branch I just made? Just try to resize again, make a log file and upload it. All it does is log some extra stuff so we can hopefully catch why exactly it's making those values 0.

d3x0r commented 4 years ago

mpv.log (plasma) sized by lower right first (no sizing) sized by top which just moves it still..

Dudemanguy commented 4 years ago

Thanks, that was quick. Actually, now I see the source of your problem here. I should have spotted it earlier.

[cplayer] VO: [gpu] 640x360 => 641x360 yuv420p

This line is in some of your older logs too. 641 is a prime number. Trying to resize this while preserving the aspect ratio will have weird behavior no matter what you do (could you confirm that the --no-keepaspect option resizes normally?) You can't reduce the size of course and the next greater size would be exactly double.

Does every single video file behave like that for you? If possible, could you upload a sample so I could confirm whether or not it's just a bad file?

d3x0r commented 4 years ago

--no-keepaspect allows resizing in any way and doesnt' seem to drop the drag...

I'm going to go with 'Every' video behaves the same way... I haven't of course played every, but I never saw one behave differently.

Dudemanguy commented 4 years ago

Thanks, I can confirm that this file is also broken for me. I'll try to figure out why the width is reported as 641 instead of 640.

mpv-player / mpv