Geometry doesn't function when hiding the taskbar

[FallenWyvern]

mpv version and platform

Latest, windows 10 but also on windows 7

Reproduction steps

Run an autoit script that hides the taskbar using this code: WinSetTrans("[Class:Shell_TrayWnd]", "", 0) ControlHide('','', WinGetHandle("[CLASS:Button]"))

I'm running MPV with the following commands: --cursor-autohide=always --hwdec=auto --no-window-dragging --no-border --no-keepaspect --ontop --osc=no --no-input-default-bindings --geometry=960x540+0+0

this is on a 1920x1080 video. I run four different videos at the same time with these commands so it should be 2x2 videos on a screen. The screen resolution is 1920x1080

Expected behavior

That four videos fill the screen.

Actual behavior

The videos play in the center of the screen with space all around them. HOWEVER this does function properly if I use "auto-hide" on the taskbar instead of hiding it via autoit.

Basically regardless of me hiding it with auto-it or not, the window draws as though the taskbar is shown.

Log file

githublog.txt

[FallenWyvern]

Note because I'm running the application 4 times, it wouldn't show in the log, so I just dropped my res to 1280 and tried to make it full screen. Same effect, but then you're not troubleshooting 4 instances.

[FallenWyvern]

So we found something that makes it work:

HKCU:SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\StuckRects3, setting the "settings" binary, 3rd option to 03 sets the bar to autohide. I don't know if you guys use that to calculate if your window is 'too large' for the desktop but with auto-hide it worked.

Also this problem is not present in 29.1, but it is present in 30.0 of MPV.

[iiiGerardoiii]

I'm having a slightly similar problem, didn't want to open a new issue because this might be duplicate.

mpv version 0.33.0-25-ga9aa5a1b1c on windows 10

My monitor is 3840x1080 and I want 1080p videos to be shown fullsize (covering the taskbar) on the right side of the monitor, but it seems mpv always shrinks the video a little bit because of the taskbar, even with --ontop enabled. I've tried these 2 commands:

mpv.exe video.mp4 --geometry=100%:0 --autofit-smaller=1920x1080 --ontop:

mpv.exe video.mp4 --geometry=100%:0 --window-scale=1 --ontop:

expectation:

If there's a command that makes it truly go fullsize please let me know.

[garoto]

Perhaps mpv --border=no --window-maximized=yes --geometry=100%:0 --autofit-smaller=1920x1080

[iiiGerardoiii]

@garoto with that command I get fullsize video but centered and pillarboxed:

[garoto]

I'm guessing this is probably the best approximation you can get currently: mpv --config=no --border=no --autofit=100%x100% --geometry=100%:0

[iiiGerardoiii]

I'm guessing this is probably the best approximation you can get currently: mpv --config=no --border=no --autofit=100%x100% --geometry=100%:0

Gives me this:

Thanks for the suggestions anyway

[veodko]

Any solution to this stupid problem? I'm having the same issue... the geometry setting is completely messed up on Windows. When I want the geometry to be 1920x1080, I want it to be 1920x1080. Why are you imposing some silly limits based on the taskbar? Same thing happens even with explorer.exe process killed when there is no taskbar. I see this issue remains open since 2019 and still persists.. There are no such issues in other apps like ffplay, they correctly display at given geometry.

I have tried numerous switches (autofit, scale, keepaspect, no-keepaspect etc) and mpv versions but nothing worked. Still the video is simply not 1920x1080. And NO, I don't want --window-maximzied or --fullscreen. I want to be able to specify the geometry manually whether it is fullscreen or half of the screen.

mpv.exe --no-config --no-border --geometry=1920x1080+0+0 snowymountain.mp4

This is displayed without explorer.exe running, the black border is actually the stupid compensation for the bottom taskbar. And nothing can be done about it. Actually, when trying to create a window larger than the screen resolution, the resulting window is completely messed up and not even positioned correctly on the screen. This makes mpv totally useless for me, despite being a great player with the most advanced config options.

[veodko]

Old versions from 2018 should supposedly not have this great "feature" but I have checked a few of them and it's all the same.

[veodko]

I have managed to find the last properly working version: mpv-i686-20181110-git-317d3ac.7z it respects the geometry setting without any retarded taskbar compensations. Kinda sad I must go with such an old version but whatever.

[Dudemanguy]

So according to the other issue, the commit that introduced this is https://github.com/mpv-player/mpv/commit/edbe25f38a2d5867dec066288cb61adf6191f327. Do you know if the changes in #9183 are related to this in anyway? That apparently also uses work area.

I agree that adding switch for this sounds reasonable.

[kasper93]

retarded taskbar compensations

I don't understand why you overreacting this much. You cannot make window bigger than your display resolution anyway. So if you do --geometry=2560x1440+0+0 it wouldn't work on 1080p display with or without this option. Taskbar is no go zone for windows in windowed mode, you have to force it on top to even make it work and even then it is not good user experience. Taskbar is also "on top", so depending on window focus it will pop on top of your oversized mpv.

You don't want fullscreen... ok. So why not (auto)hide taskbar? Show it only on one screen or any other normal solution to reclaiming this working area for your application.

Form your reaction I though this is severely bugged, but everything works as expected, properly scaling per screen, depending on taskbar hide state and so on.

I agree that adding switch for this sounds reasonable.

Sure, option doesn't harm. But it has been years and if it were a real issue, someone would contribute it already. So far 3 people were complaining :)

[veodko]

Imagine that some people want to use mpv for something more complicated than just one simple window positioned safely on the user's screen work area. For this I'd just use windows built in media player. Let's say you want to display 2 borderless videos at the same time on the left and right side of the screen. You can't do that with fullscreen, but setting 1080p or 100% as height won't work because of the taskbar. Which isn't even there, because I'm killing the explorer.exe process.

Why not autohide? Because it either requires the user to click it himself in the settings or needs some little more advanced modifications inside the windows registry, which I'd rather not do. I like to use mpv because it has great support, easy install and rich configuration not mentioning this one thing, which is nonexistent in either ffplay or gstreamer that I have used earlier. In fact, I have never seen such a limitation anywhere else. Maybe when resizing the windows due to video change it would make sense, but if I'm specifying the window size by hand using the --geometry switch, just let it be my way as I know what I want to achieve.

I have yet to try if hiding the taskbar through winapi affects this. I forgot there is such an option, although killing explorer.exe is simpler as it also hides the desktop.

[FallenWyvern]

And if I can comment, since I created the thread originally:

When I made the submission, the software worked one way and then it didn't. The software was being used in a commercial product. We found a workaround, but the important thing was to notify those writing the code that something changed and it wasn't in the changelog.

If it was intentional and by design, great. Our workaround would have to suffice, or we'd have to revert to an older version of the software... but if that change wasn't intentional? As a coder, I would want to know when something unexpectedly changed so I can fix it.

It's not about complaining, it's about consistency. What if this was indicative of a change in how Microsoft was reporting desktop resolution and the people coding MPV didn't encounter the problem? They need to create a case for it, but unless someone reports it, they'd never know.

[Dudemanguy]

So if you do --geometry=2560x1440+0+0 it wouldn't work on 1080p display with or without this option.

I would expect this to work if the window manager/compositor doesn't limit mpv from doing this in some way. It works on my machine anyway, but I don't know if that's different on windows.

[kasper93]

I would expect this to work if the window manager/compositor doesn't limit mpv from doing this in some way. It works on my machine anyway, but I don't know if that's different on windows.

Yes, it is limited to virtual screen space by DWM.

It's not about complaining, it's about consistency. What if this was indicative of a change in how Microsoft was reporting desktop resolution and the people coding MPV didn't encounter the problem

mpv (as a community) is not Microsoft, it is open source software distributed without any warranty. You cannot expect, nor should you expect any consistency from bunch of volunteers that work on this project. It is not commercial project, it doesn't provide any support. But I'm sure if you asked for paid support it would be resolved sooner.

And this is why contributing to open source sucks, you get bunch of people who get your software for free, even use if for commercial purposes and all you get in return is being called "retard" or features "retarded".

I will sign off from this discussion with funny image (XKCD #1172):

[kasper93]

Sorry I missed one comment

Why not autohide? Because it either requires the user to click it himself in the settings or needs some little more advanced modifications inside the windows registry, which I'd rather not do. [...] I have yet to try if hiding the taskbar through winapi affects this. I forgot there is such an option, although killing explorer.exe is simpler as it also hides the desktop.

Dude, you are killing explorer.exe or trying to hide it with winapi, and saying that changing one option in Windows settings is too much of a hassle? Ok, I don't have to understand. But if it is really a trouble you can always send a PR to mpv to add an option to disable this "retarded feature".

[v1934]

Dude, you are killing explorer.exe or trying to hide it with winapi, and saying that changing one option in Windows settings is too much of a hassle? Ok, I don't have to understand. But if it is really a trouble you can always send a PR to mpv to add an option to disable this "retarded feature".

Enabling this feature programmatically (if you want to do an automated install, you'd rather not tell the user "go to your windows settings and check this checkbox"), looks like this: powershell -command "&{$p='HKCU:SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\StuckRects3';$v=(Get-ItemProperty -Path $p).Settings;$v[8]=2;&Set-ItemProperty -Path $p -Name Settings -Value $v;&Stop-Process -f -ProcessName explorer}" And it still needs to restart the explorer.exe process for this change to even work. Hiding the taskbar from C WinAPI does not fix this issue. The videos still are bordered.

And this is why contributing to open source sucks, you get bunch of people who get your software for free, even use if for commercial purposes and all you get in return is being called "retard" or features "retarded".

IMO it kinda sucks to mindlessly introduce such changes into a public repo used by thousands of people without giving any ability to opt out of them. But someone should accept this when merging the PR.

[Dudemanguy]

This is a github issue page not a public debate forum, so I think we can cut the discussion off here. The way forward is for someone to write a patch for this. I will be happy to review it and merge it if it looks good and fixes the issue.

[kasper93]

Hiding the taskbar from C WinAPI does not fix this issue. The videos still are bordered.

This I believe warrants a bugfix, to properly detect this state. Probably the metrics returned by winapi doesn't include this. As @Dudemanguy said, send a patch, it will take less time to create a patch than you guys trying to prove the point.

IMO it kinda sucks to mindlessly introduce such changes into a public repo used by thousands of people without giving any ability to opt out of them. But someone should accept this when merging the PR.

Yes, now imagine that 99% of said people are happy with the changes, stop projecting your opinion on the whole userbase. I already said, this "feature" were introduced in 2018 and since then only handful of unsatisfied people emerged and no one provided a patch. Can't make everyone happy, I guess.

Sorry for discussing this. I probably should say anything, but it is just disheartening how demanding some people are for no reason.

It was my last message here.