Also, if the position is valid, set it to 1 / INF. Windows interprets 0
as non-progress.
Progress is quantized into uint8 range, it is good enough for this
use-case. This avoids unnecessary vo_control and
ITaskbarList3::SetProgressValue calls and should be visually
indistinguishable in practice.
Fixes#14282
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.
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.
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.
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.
win32 does not respect --native-keyrepeat option, and native key
repeat has been broken since 0ab3482f73.
This lets mpv respect the --native-keyrepeat option on win32.
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.
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.
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.
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.
5736737750 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.
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.
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.
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.
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 bf6b981367.
In commit c09245cdf2
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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
Kacper Michajłow
nanahi
Shuanglei Tao
Dudemanguy
sfan5
NRK
sunpenghao