summaryrefslogtreecommitdiffstats
path: root/video/out/w32_common.c
Commit message (Collapse)AuthorAgeFilesLines
* win32: fix maximize state with --border=noKacper Michajłow34 hours1-6/+10
| | | | | | WS_POPUP windows cannot be maximized, so instead of forcing it with unavoidable side-effects, change the window style before maximizing to make it work correctly.
* win32: make context menu items accessible from the window menunanahi3 days1-2/+13
| | | | | | This makes the context menu items accessible from the window menu, which can be opened by either right-clicking on the title bar or left-clicking on the mpv icon on the title bar.
* win32: move context menu init/uninit to GUI threadnanahi3 days1-2/+3
| | | | | | | | | Currently if VO init fails, the context menu is leaked. Additionally, init/uninit are in the VO thread, while other accesses are in the GUI thread. Fix this by moving them to the GUI thread, similar to other resources. This also lets init function take the mpv HWND in the next commit.
* win32: support multitouchnanahi3 days1-7/+54
| | | | | Use the multitouch API. To disable system's defualt mouse emulation, set --native-touch=yes.
* w32_common: fix show-in-taskbar toggling after explorer is restartednanahi10 days1-2/+8
| | | | | | | | | | | | | | | | | After explorer is restarted while show-in-taskbar is false, toggling show-in-taskbar no longer puts mpv back to the taskbar until it's unfocused and refocused. My guess of how this works is that the HWND of the taskbar is cached, and setting the WS_EX_TOOLWINDOW style internally uses this value to show/hide the taskbar button. But after explorer is restarted it no longer works until its taskbar state needs to change (such as focusing). Only then it realizes the HWND is no longer valid and refreshes it. Fix this by following MS documentation on this: the window needs to be hidden before changing the style, and be shown after that. This unfortunately can sometimes introduce a brief window flash, but it fixes the problem.
* w32_common: implement --show-in-taskbar optionnanahi2024-04-181-1/+12
| | | | | When the window style changes, use WS_EX_TOOLWINDOW style to exclude the window from the taskbar and Alt+Tab switching.
* vo: add win32 context menu supportShuanglei Tao2024-04-061-0/+24
|
* win32: fix native key repeat supportnanahi2024-03-291-5/+2
| | | | | | | win32 does not respect --native-keyrepeat option, and native key repeat has been broken since 0ab3482f73a199b2e839ad4ec0a4b21adc1e75d5. This lets mpv respect the --native-keyrepeat option on win32.
* win32: remove all NC area on Windows 10 with --title-bar=noKacper Michajłow2024-03-181-3/+12
| | | | | | | | | Windows 10 top bar height cannot be adjusted individually when WS_CAPTION is enabled due to buggy DWM NC drawing behavior. The issue is fixed in Windows 11. To keep consistent window look remove the border on each side, but only on Windows 10.
* win32: add helper function to check Windows 10 build numberKacper Michajłow2024-03-181-8/+20
|
* win32: adjust top border offset when title bar is disabledKacper Michajłow2024-03-181-18/+52
| | | | | | | | | | | | | | | Windows 11 draws border regardless, so we are 1px off on window size, blending border with one line of video. Fix that by adding the border to our internal windows size calculation. Windows 10 on the other hand has a bug where specifying left and top NC area will trigger title bar drawn in full height always. Keep old behaviour in this case. Also while there is similar "visible" border there, it seems to be transparent on Windows 10. For high contrast themes, don't adjust title bar height and instead remove WS_CAPTION to have the same border all around the window, as DWM doesn't make borders invisible in this case.
* win32: add DWMWA_VISIBLE_FRAME_BORDER_THICKNESS definitionKacper Michajłow2024-03-181-1/+8
|
* win32: use dpi aware GetSystemMetricsForDpiKacper Michajłow2024-03-181-9/+19
|
* win32: update maximized state when leaving fullscreennanahi2024-03-181-6/+7
| | | | | If the window-maximized is set while in fullscreen, it needs to be applied when leaving fullscreen, as noted in the comment.
* win32: fix window maximized state after setting window sizenanahi2024-03-181-0/+20
| | | | | | | | | | | With runtime geometry change, currently it only results in a SetWindowPos call to resize the window. However, SetWindowPos doesn't change the window maximized state, so Windows still thinks that the window is maximized even though it no longer covers the whole workspace. This results in visual glitches, and if the window is dragged afterwards it's "restored" again. Fix this by correctly setting the window maximized state in this case.
* win32: support runtime geometry updatenanahi2024-03-171-5/+13
| | | | | Similar to other platforms. Also make sure that the x/y positions are set on geometry update.
* w32_common: make dragging asynchronousnanahi2024-03-011-1/+8
| | | | | | | | | | | | | | VOCTRLs are processed in the GUI thread through the mp_dispatch mechanism. Window dragging requests are asynchronous on x11 and wayland, so the item is processed quickly without problem. However, currently win32 uses the SendMessage call for this, which is synchronous. This causes the playback to stop while the dragging request is being processed because the dispatch queue is blocked. Work around this by setting a flag instead if the window dragging is requested, and immediately starts dragging after processing the dispatch queue. This doesn't block the dispatch queue while also avoiding any extra latency added by the Windows message queue.
* w32_common: re-add fullscreen check when start draggingnanahi2024-03-011-1/+2
| | | | | | | | | | 57367377505b6b2edc87004fa3192d831d515aa5 removed the check because it was not needed to prevent fullscreen window from being dragged. However, this causes an undesirable behavior: when using a touch screen to drag a window on Windows 11, DWM shrinks the window content a bit with an acrylic backdrop to indicate that the window is being dragged. This also happens when trying to drag the window in fullscreen. Add the check to prevent this from happening.
* input: centralize VO draggingnanahi2024-03-011-7/+0
| | | | | | | | | | | | | | | | | | | | | | Currently, VO dragging logic is hardcoded into each VO, where a left mouse button down event unconditionally begins dragging if the VO dragging test passes. This method is extremely unflexible as the VO has no knowledge of what is happening in the input system: while begin dragging with the second click of a doubleclick is undesired, it cannot determine whether a click is a double click or not because it's determined by the input system. The better way to do it is to handle it somewhere in the downstream consumers of the events instead, as they have more information to make this decision. The input system is the perfect place for this as the logic for checking doubleclick already exists. So just issue a begin-vo-dragging command if it detects a left mouse button down which isn't also a doubleclick in this case, and delete all hardcoded VO dragging logic in win32, x11, and wayland. Note that this solution hardcodes left mouse button down for now, but because the VO dragging is now centralized, it's possible to make more improvements, such as a deadzone mechanism to fix the conflict with MBTN_LEFT mouse bind.
* w32_common: implement VOCTRL_BEGIN_DRAGGINGnanahi2024-03-011-18/+27
| | | | | | | This allows begin-vo-dragging command to initialize a vo dragging request for win32. Also set dragging to release all keys like for other platforms. The hard-coded left mouse button down trigger is scheduled to be removed in a later commit.
* win32: clean up hidpi window scale behaviorDudemanguy2024-02-241-6/+3
| | | | | Same as X11. An accurate dpi scale should always be reported and UNFS_WINDOW_SIZE shouldn't take dpi scale as an additional multiplier.
* w32_common: add function to control window transparency statenanahi2024-02-171-0/+21
| | | | Use the DWM API to enable and disable compositor transparency.
* various: replace dead links in commentsnanahi2024-02-111-4/+5
| | | | | Replace various dead links with live replacements or archives. Less friction for anyone who wants to look up these references.
* win32: stop waiting for messages if the window is destroyednanahi2024-01-211-1/+1
| | | | GetMessageW will indefinitely block after the window is destroyed.
* win32: change to alphanumeric mode on the first keypressnanahi2024-01-151-0/+10
| | | | | | Needed in case the timer solution fails. Note that this will leave the mode indicator in the language bar showing the original mode until a key is pressed.
* win32: default to alphanumeric input when the IME is first initializednanahi2024-01-151-0/+30
| | | | | | Some IMEs initialize to composition mode for new windows, which is undesirable for keyboard control. Default to alphanumeric input to solve this.
* win32: move IME candidate window to video windownanahi2024-01-151-0/+9
| | | | | By default the IME candidate window appears on the top left corner of the monitor. Move it to the video window for sane behavior.
* win32: handle WM_UNICHARnanahi2024-01-151-3/+10
| | | | WM_UNICHAR is sent by some 3rd-party IMEs.
* win32: re-enable IMEnanahi2024-01-151-12/+11
| | | | | | | | | | The IME is useful for text input. Additionally, Alt+Shift input language switching doesn't work when IME is disabled even when the languages don't require IME. Re-add the VK_PROCESSKEY logic to ensure that IME is handled properly. Reverts bf6b981367e45c3f926d3e667bba3f3ed6e9dc37.
* win32: add support for --input-cursor-passthrough optionnanahi2023-12-281-0/+21
| | | | This completes the support for all supported desktop platforms.
* various: use correct PATH_MAX for win32sfan52023-12-271-2/+4
| | | | | | | | In commit c09245cdf2491211f3e0bfe47f28cc0e0a2e05c8 long-path support was enabled for mpv without actually making sure that there was no code left that used the old limit (260 Unicode chars) for buffer sizes. This commit fixes all but one case.
* w32_common: remove executable bit from fileDudemanguy2023-12-151-0/+0
| | | | | 57367377505b6b2edc87004fa3192d831d515aa5 mistakenly changed the mode from 644 to 755. Change it back.
* w32_common: rename some camelCase struct member names to snake_casenanahi2023-12-101-9/+9
|
* win32: temporarily disable aero shake while dragging hack is activenanahi2023-12-101-0/+10
| | | | | | | The dragging hack can cause unwanted aero shake activation. Prevent this by saving the window arrangement state before dragging, temporarily disable it while dragging hack is active, and restore to the original state after dragging ends.
* win32: stop fullscreen window from moving while dragging hack is activenanahi2023-12-101-3/+17
| | | | | | | | | | | | | | | | | | | | | The mouse down handler checks w32->current_fs to determine whether to begin the dragging hack. Unfortunately, the w32->current_fs value is stale, because the input is handled asynchronously, and we cannot wait for an up-to-date value if dragging needs to be kept resonsive. As a result, when the fullscreen state changes after the dragging model loop is entered, the opposite value is used, so the window stays draggable after entering fullscreen, and becomes undraggable after exiting fullscreen. With the resonsiveness and model loop constraints, the up-to-date state must be queried inside WM_MOVING messages which are sent while dragging. The message handler now checks if the dragging hack is active while the window is in fullscreen, and overrides the new window position with the current one, in effect prevents the window from being moved. The old check is also removed, so the window is now draggable after exiting fullscreen while dragging hack is active.
* win32: properly handle WM_XBUTTONUP and WM_XBUTTONDOWNnanahi2023-12-061-2/+2
| | | | | | | | | | | | | | | | According to MS documentation, an application should return TRUE from WM_XBUTTONUP and WM_XBUTTONDOWN if it processes these messages. DefWindowProc generates the WM_APPCOMMAND message when it processes the WM_XBUTTONUP message, so if an application properly handles WM_XBUTTONUP messages, extra WM_APPCOMMAND messages won't be generated. Because mpv doesn't properly handle these messages, WM_XBUTTONUP causes APPCOMMAND_BROWSER_BACKWARD to be generated, resulting in duplicated keys and improper fix 438ead7a, which prevents the processing of the appcommand from sources other than mouse clicks. Fix this by following the documentation, and the back and forward appcommands can be added.
* win32: fix hit test using client rc instead windowKacper Michajłow2023-11-071-16/+20
| | | | | | | | | windowrc in vo_w32_state is actually client size, for hit test we need proper window size. When border is disabled those sizes are the same, but when only title bar is disabled it is not. Reduce the hit area to more sane values when the border is not drawn to minimize amount of covered client area in borderless mode.
* ALL: use new mp_thread abstractionKacper Michajłow2023-11-051-10/+9
|
* win32: add more values for monitor refresh rate detectionnanahi2023-11-021-0/+4
| | | | | Add more refresh rates for get_refresh_rate_from_gdi() now (Nov 2023) that 165 Hz is common, 240 Hz is on the rise, and 120 * N Hz is the future.
* mp_threads: rename threads for consistent naming across all of themKacper Michajłow2023-10-271-1/+1
| | | | | | | | I'd like some names to be more descriptive, but to work with 15 chars limit we have to make some sacrifice. Also because of the limit, remove the `mpv/` prefix and prioritize actuall thread name.
* various: sort some standard headersNRK2023-10-201-3/+4
| | | | | | | | | | | | since i was going to fix the include order of stdatomic, might as well sort the surrouding includes in accordance with the project's coding style. some headers can sometime require specific include order. standard library headers usually don't. but mpv might "hack into" the standard headers (e.g pthreads) so that complicates things a bit more. hopefully nothing breaks. if it does, the style guide is to blame.
* osdep: remove atomic.hNRK2023-10-201-1/+1
| | | | | | | replace it with <stdatomic.h> and replace the mp_atomic_* typedefs with explicit _Atomic qualified types. also add missing config.h includes on some files.
* win32: suppress pointer cast warningKacper Michajłow2023-10-191-1/+1
|
* win32: clear background only on first paintKacper Michajłow2023-10-181-1/+4
| | | | | | | | | Some users report visible black frames during window resize, this should not happen in most cases. Let's just keep stale content as it is less distracting. While still clearing on first window paint to avoid white background. Fixes: #12642
* win32: improve window snapping behaviorsunpenghao2023-10-101-53/+113
| | | | | | | | | | | Several window resizing operations (i.e., --auto-window-resize, border dragging with --keep-aspect-window, Alt+0/1/2) cause the window to detach from the snapped borders. This patch resolves this by recording to which borders the window is snapped, and using this info to determine how the window should be placed after resizing. Closes https://github.com/mpv-player/mpv/issues/6588
* win32: clear client area to black earlyKacper Michajłow2023-10-051-2/+5
| | | | | | | | | | | | This fixes white background appearing for short period of time before first frame is drawn. Clear to black as this is way less distracting than bright white flash. Borderless window and fullscreen seems to be initially not drawn/transparent, so no need to clear it to black. Only when decorations are enabled (--border) the issue happens. Fixes: #12549
* win32: adjust WM_NCACTIVATE for better compatibility with window stateKacper Michajłow2023-10-021-2/+4
| | | | We have to support all changing states, not only borderless.
* win32: add WS_THICKFRAME style in borderless modeKacper Michajłow2023-10-011-1/+9
| | | | | | Fixes window resizing in borderless mode after adding WS_SYSMENU. Fixes: 172d9be3005c6a85f4f139f1dedccefe26ea8d91
* win32: set WS_SYSMENU style alwaysKacper Michajłow2023-10-011-1/+2
| | | | | | Fixes missing icon when initial window is created without caption. Fixes: #12472
* win32: add option to change backdrop styleDeadSix2023-09-271-0/+17
|
* win32: pass window handle to the window-id propertyDeadSix272023-09-251-0/+6
| | | uses the same mechanic as for x11
* win32: don't remove WS_CAPTION from styleKacper Michajłow2023-09-211-23/+16
| | | | | | | | Apparently removing WS_CAPTION disables some window animations. Instead adjust non-client area to not draw title bar. Note that we do not account for difference in real border size and invisible one, but seems to work correctly.
* win32: enable custom WM_NCHITTEST also when title bar is hiddenKacper Michajłow2023-09-211-1/+1
|
* win32: set window_corners to default for fullscreenKacper Michajłow2023-09-211-6/+10
| | | | | | I don't think in fullscreen mode it makes sense to enable rounded corners. We can add another option if someone needs it, but for now `window_corners` affects only the window as one would expect.
* win32: add --window-cornersKacper Michajłow2023-09-211-0/+11
| | | | Allows to set preference for window corners rounding for DWM.
* win32: fix fit_window_on_screen to account for invisible bordersKacper Michajłow2023-09-211-0/+12
| | | | Fixes too small initial window size.
* win32: reduce top border thickness to imitate DWM invisible bordersKacper Michajłow2023-09-211-0/+30
| | | | DWM makes part of left, right and bottom border invisible.
* win32: add an option to control window title bar stateKacper Michajłow2023-09-211-1/+5
| | | | Fixes: #11432
* win32: add an option to change window affinityDeadSix2023-09-211-0/+14
|
* win32: explicitly guard dark mode calls by Windows versionKacper Michajłow2023-09-211-2/+14
| | | | | Fixes: #11610 Fixes: 9feeb324eddd9ed73ae667e10275f663d70f7544
* win32: remove noisy debug logKacper Michajłow2023-09-171-1/+0
| | | | It is quite unnecessary to log every window move.
* win32: don't ignore --screen and --fs-screenKacper Michajłow2023-08-231-8/+14
| | | | | Fixes: 57ba77fc736f6976bc114974f5955c972139740f Fixes: #12220
* w32_common: try to get the monitor from the window boundsZenos2023-08-201-1/+5
|
* w32_common: don't fit to screen when VO_WIN_FORCE_POS is setZenos2023-08-201-1/+1
|
* win32_common: fixes minimized window being focused on launchmwalmer2023-08-201-1/+1
| | | | | | mpv was taking focus when being started with "--window-minimized=yes". This change stops mpv from taking focus when this option is used. Resolves: #9641
* win32: fix display resolution calculation on mulitple monitorsDudemanguy2023-08-151-3/+3
| | | | | | | It was actually always wrong, and no one ever noticed. This currently returns the size of the entire display area and not one actual monitor. Fix this by calling get_monitor_info and then doing the appropriate subtractions. Checked by @CrendKing and fixes #12172.
* win32: signal VO_EVENT_DPI on dpi changesDudemanguy2023-08-061-0/+1
| | | | | | | The win32 code already updates itself on dpi changes. However, it never signalled mpv's core when this happened which meant that the display-hidpi-scale property never changed. S