mac: add support for --force-window-position

[NekoAsakura]

(that's a lot less changes than i anticipated.)

This pull request includes a bug fix and adds support for a feature.

---

1. In Common::getWindowGeometry -> (NSRect, Bool)
   

   mpv/video/out/mac/common.swift

   Line 440 in dbb3291

   return (wr, Bool(geo.flags & Int32(VO_WIN_FORCE_POS)))

Int32(VO_WIN_FORCE_POS) is always a constant 1, irrespective of --force-window-position. As a result, whenever --geometry is passed, forcePosition is returned as 1.

You can easily verify this by:
a) Adding a breakpoint just before the return statement, or
b) Including a debug line such as print("Bool", Bool(geo.flags & Int32(VO_WIN_FORCE_POS)))
Then:

build/mpv --geometry=500:500 '/Users/neko/Downloads/test.mp4'
build/mpv --geometry=500:500 --force-window-position '/Users/neko/Downloads/test.mp4'

---

[Notice] The objc func control used variable forcePosition in one case within a switch statement. However, I don't know the corresponding trigger condition. Could someone who knows provide the related code or help me test it?

mpv/video/out/mac/common.swift

Line 537 in dbb3291

let (_, wr, forcePosition) = self.getInitProperties(vo)

---

2. Add support for --force-window-position
   simple.
   https://developer.apple.com/documentation/appkit/nswindow/ismovable

[NekoAsakura]

After testing, it was found that the mouse can still interact with the NSView (rather NSWindow) to move the window. This issue is currently being fixed.

[github-actions]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32
• mpv-x86_64-windows-msvc

macOS

• mpv-macos-13-intel
• mpv-macos-14-arm
• mpv-macos-15-arm

[NekoAsakura]

Fixed. I assume that --force-window-position does not want to disable full-screen mode. Let me know if further adjustments are required.

[Akemi]

sry this is not doing what the option is supposed to do.

[Akemi]

that's wrong. this is a bitwise and operation, eg it is supposed to check if VO_WIN_FORCE_POS is included in the set bits of geo.flags. in this case it's already properly set in the underlying function, eg the geo pointer that is passed to vo_calc_window_geometry.

mpv/video/out/win_state.c

Lines 137 to 139 in dbb3291

	if (opts->geometry.xy_valid || opts->force_window_position || force_center)
	out_geo->flags |= VO_WIN_FORCE_POS;
	}

see also other implementations https://github.com/search?q=repo%3Ampv-player%2Fmpv%20VO_WIN_FORCE_POS&type=code

[Akemi]

you can just use option (class var), no need to instantiate a new option helper

[Akemi]

are you misunderstanding the option here (https://github.com/mpv-player/mpv/blob/master/DOCS/man/options.rst?plain=1#L3569-L3572)?

Forcefully move mpv's video output window to default location whenever
there is a change in video parameters, video stream or file. This used to
be the default behavior. Currently only affects X11 and SDL VOs.

this just prevents window dragging on title bar and background.

i believe the only part missing here is the the position on init. though i have to check what exactly didn't work properly.

[NekoAsakura]

I shall have a look.

[NekoAsakura]

@Akemi Hi, I reviewed the code, and for the first commit, my question is:

mpv/video/out/win_state.c

Line 137 in dbb3291

if (opts->geometry.xy_valid || opts->force_window_position || force_center)

Why it's
opts->geometry.xy_valid || opts->force_window_position || force_center rather
opts->geometry.xy_valid && opts->force_window_position || force_center?
Is this the intended behaviour?

As for the second commit, yes, I misunderstood the meaning of this option. My current understanding is that when running the script below, the option expects the top-left corner of the window (as defined by the geometry setting) to remain fixed when switching between different resolutions. Is that right?

#!/usr/bin/env bash

EXEC_PATH="mpv"

while [[ "$1" != "" ]]; do
    case "$1" in
        --exec_path )
            shift
            EXEC_PATH="$1"
            ;;
    esac
    shift
done

RESOLUTIONS=(
"1280x720"
"854x480"
"640x360"
"426x240"
)

DURATION=1.5

rm -f res_*.mkv list.txt recycle.mkv

for RES in "${RESOLUTIONS[@]}"; do
    WIDTH=$(echo $RES | cut -d'x' -f1)
    HEIGHT=$(echo $RES | cut -d'x' -f2)
    OUTPUT="res_${WIDTH}x${HEIGHT}.mkv"
    ffmpeg -f lavfi -i "testsrc=size=${WIDTH}x${HEIGHT}:rate=30:duration=${DURATION}" -pix_fmt yuv420p -c:v libx264 -crf 20 -y "${OUTPUT}"
    echo "file '$(pwd)/${OUTPUT}'" >> list.txt
done

ffmpeg -f concat -safe 0 -i list.txt -c copy recycle.mkv

rm -f res_*.mkv list.txt

ffmpeg -stream_loop -1 -re -i recycle.mkv -c copy -f matroska - 2>/dev/null | "${EXEC_PATH}" --geometry=500:500 --force-window-position -

Save it into test_force_pos.sh and run

bash ./test_force_pos.sh

or

bash ./test_force_pos.sh --exec_path <your_compile_path>

[Akemi]

1. yes, i think it's intended.
2. force-window-position is independent from geometry options but can be influenced by it. my understanding of this option is, when used the position of the window is reset (to default position) every time "there is a change in video parameters, video stream or file".

specific example, without geometry options set but with --force-window-position:

1. open a video file, the window is centered on the current screen
2. move the window somewhere else on that screen
3. file changes to the next video file > window is forced to the default location (centered on the screen). default location is the same location as opening the file directly on init. without force-window-position the file stays at the location from 2., though is 'centered resized'

the default location can be influenced by the various geometry/autofit options.

[Akemi]

for macvk this most likely needs to be added here.

the manual needs updating to for this option, when adding this https://github.com/mpv-player/mpv/blame/master/DOCS/man/options.rst#L3569-L3572

[NekoAsakura]

@Akemi, could you review the newly submitted commit? Now the fixed position is anchored to the top-left corner. (centre alignment would be more complex as window?.unfsContentFrame is affected when user moving and resizing window, we might need a new variable to store last initial parameters.)

[Akemi]

i don't know what you mean "Now the fixed position is anchored to the top-left corner"? what exactly is the problem or what behaviour changed from the previous behaviour? the frame is set according to what vo_calc_window_geometry returns.

please also update the manual.

[NekoAsakura]

I don’t have an X11 testing environment, so I’m unsure about the behaviour of --force-window-position on other VOs. When using --force-window-position, we need to define an original point, which is currently set to the top-left corner. This is because, on macvk, the window position is updated by CGRect, and the original of CGRect is in the upper-left corner -- when we defined it with a flipped coordinate space. I simply want to confirm that this original point is the desired one (or at least consistent with the behaviour of other VOs).

[Edit]
When update manual, should I name it 'cocoa-cb' or 'macvk'?

[Akemi]

first of all the manual is not completely clear how this is supposed to behave especially with --auto-window-resize. on X11 --force-window-position apparently it's just a recenter window. i am in the process to clarify how this is supposed to work.

i am not sure why it's relevant that the window is positioned by the top left corner? it was like this before and is supposed to be like that (see geometry https://github.com/mpv-player/mpv/blob/master/DOCS/man/options.rst?plain=1#L3398-L3399 "from the top-left corner"). if it were an issue, it would be unrelated to this and would need fixing somewhere else (eg we only flip the origin here https://github.com/mpv-player/mpv/blob/master/video/out/mac/common.swift#L436-L437 to align it with the macOS coordinate system).
you update the whole frame, which is calculated taking the size into consideration, so it is kinda irrelevant atm. if we would only update the position though and expect a centered window that would be a completely different matter.

either macOS or macvk, the former if we update cocoa-cb too to support this.

[NekoAsakura]

Then it seems there’s nothing more to modify in this PR.

However, I did notice that the geometry calculations are incorrect. In my test code, I used --geometry=500:500, but the result was (308, 275). Can you verify this issue?

[Akemi]

i can't verify nor deny any issue like this. this depends on your setup (hdipi, resolution, screen, config, etc) and which values you actually compare. this is the wrong place for reporting an issue in the first place.

a simple check on my setup does what it is supposed to do on the main monitor. though that doesn't mean that something isn't broken or broke at some point because of various reasons.

[NekoAsakura]

It is certainly not a requirement for this PR. I’m just mentioning it to see if this issue has already been identified. I will carry out a full test later and submit a new issue.