Previously, mpv would hide the cursor when the autohide timer expired,
even if the window menu was open. This made it difficult to use the menu
with the mouse.
When handling VOCTRL_SET_CURSOR_VISIBILITY, instead of determining
whether to call SetCursor by checking if the cursor is in the client
area, call it based on the parameters to the last WM_SETCURSOR message.
When the window enters "menu mode," it gets a WM_SETCURSOR message with
HIWORD(lParam) set to 0 to indicate that the cursor shouldn't be set.
At least the opengl-hq VO allocates additional resources when
downscaling a lot, which is just a waste.
Also see #1547 (although I doubt that this is the cause; if it is,
a real fix will be required).
The "ontop" and "border" properties already used a common
mp_property_vo_flag() function, and the corresponding VOCTRLs used the
same conventions. "fullscreen" is pretty similar, but was handled
slightly similar. Change how VOCTRL_FULLSCREEN behaves, and use the same
helper function for "fullscreen" as the other flags.
Windows uses a heuristic to determine if a window should appear
fullscreen. If the active window's client area covers the whole screen,
the taskbar should move to the bottom of the Z-order, allowing the
window to show through.
Unfortunately, sometimes it doesn't work and the taskbar stays on top of
the "fullscreen" window. ITaskbarList2->MarkFullscreenWindow explicitly
tells the shell that a window wants to be fullscreen, so the taskbar is
always at the bottom of the Z-order while the marked window is active.
This might help with #999. Firefox also uses this interface to fix
fullscreen issues.
MS Windows doesn't allow windows larger than the screen, so we include
a hack to make the window smaller. This hack recenters the window (what
else would it do?).
It didn't account for the virtual offset of the current screen, and it
was reported that it forces the window to the first screen.
Should fix#1292.
This reverts commit d859549424.
Going to apply the alternative fix through PR #1256, which came just
some seconds after pushing the reverted commit. The reverted commit
was reported as not actually working.
Especially with other components (libavcodec, OSX stuff), the thread
list can get quite populated. Setting the thread name helps when
debugging.
Since this is not portable, we check the OS variants in waf configure.
old-configure just gets a special-case for glibc, since doing a full
check here would probably be a waste of effort.
As I understand, otherwise, the code will try to destroy the same
window again in the cleanup part of the gui_thread(), which makes no
sense and is potentially dangerous.
When embedding, if the parent window is destroyed, it will cause mpv's
window to be destroyed as well. Since WM_USER wakeups are sent to the
window, destroying the window will prevent wakeups and cause uninit to
hang.
Fix this by quitting the event loop on WM_DESTROY. Events should only be
processed for the lifetime of the window, from CreateWindowEx to
WM_DESTROY. After the event loop is finished, mp_dispatch_queue_process
can handle any remaining requests.
An attempt at fixing #1070. Apparently something goes wrong if the
video size is equal to the screen size. Since the window decorations
add to the window size, it must actually be larger than the screen.
Actually I don't know what exactly is going wrong, but since this
commit also slightly improves the behavior otherwise, it's a win
anyway.
Try to keep the window size strictly below screen size, even accounting
for window decorations. Size it down and center the window so that it
fits (by either touching the left/right or top/bottom screen borders).
I haven't found any information on what is the maximum allowed size and
position of a window so that it doesn't collide with the task bar, so
assume that we can use the entire screen, minus 1 pixel to avoid
triggering fullscreen semantics (if that is even possible).
reinit_window_state() will set VO_EVENT_RESIZE when it runs, so we
don't need to set it manually depending on the VOCTRL.
Probably avoids duplicated resize events. I don't expect this actually
fixes anything, but might help spotting other bugs easier (if there
are any).
The VO is run inside its own thread. It also does most of video timing.
The playloop hands the image data and a realtime timestamp to the VO,
and the VO does the rest.
In particular, this allows the playloop to do other things, instead of
blocking for video redraw. But if anything accesses the VO during video
timing, it will block.
This also fixes vo_sdl.c event handling; but that is only a side-effect,
since reimplementing the broken way would require more effort.
Also drop --softsleep. In theory, this option helps if the kernel's
sleeping mechanism is too inaccurate for video timing. In practice, I
haven't ever encountered a situation where it helps, and it just burns
CPU cycles. On the other hand it's probably actively harmful, because
it prevents the libavcodec decoder threads from doing real work.
Side note:
Originally, I intended that multiple frames can be queued to the VO. But
this is not done, due to problems with OSD and other certain features.
OSD in particular is simply designed in a way that it can be neither
timed nor copied, so you do have to render it into the video frame
before you can draw the next frame. (Subtitles have no such restriction.
sd_lavc was even updated to fix this.) It seems the right solution to
queuing multiple VO frames is rendering on VO-backed framebuffers, like
vo_vdpau.c does. This requires VO driver support, and is out of scope
of this commit.
As consequence, the VO has a queue size of 1. The existing video queue
is just needed to compute frame duration, and will be moved out in the
next commit.
Sometimes GetClientRect() appeared to fail during init, and since we
don't check GetClientRect() calls (because they're on our own window,
and logically can never fail), bogus resizes were triggered. This could
cause vo_direct3d to fail initialization.
The reason was that w32->window was set to 0 during early window
initialization: CreateWindow*() can send messages to the new window,
even though it hasn't returned yet. This means w32->window is not yet
set to our window handle, and functions in WndProc may accidentally pass
hwnd=0 to win32 API functions.
Fix it by initializing w32->window on opportunity. This also means we
always strictly expect that the WndProc is used with our own window
only.
This fixes the fullscreen issues on Intel for me. I'm baffled by it and
don't understand why this suddenly works. Intel drivers being shit?
Windows being shit? HWND or HDC being only 97% thread-safe instead of
98%? Me missing something subtle that is not documented anywhere?
Who knows.
Now instead of creating the HDC and OpenGL context on the renderer
thread, they're created on the GUI thread. The renderer thread will
then only call wglMakeCurrent, SwapBuffers, and OpenGL standard
functions.
Probably fixes github issue #968.
The windows message loop now runs in a separate thread. Rendering,
such as with Direct3D or OpenGL, still happens in the main thread.
In particular, this should prevent the video from freezing if the
window is dragged. (The reason was that the message dispatcher won't
return while the dragging is active, so mpv couldn't update the
video at all.)
This is pretty "rough" and just hacked in, and there's no API yet to
make this easier for other backends. It will be cleaned up later
once we're sure that it works, or when we know how exactly it should
work. One oddity is that OpenGL is actually completely managed in the
renderer thread, while e.g. Cocoa (which has its own threading code)
creates the context in the GUI thread, and then lets the renderer
thread access it.
One strange issue is that we now have to stop WM_CLOSE from actually
closing the window. Instead, we wait until the playloop handles the
close command, and requests the VO to shutdown. This is done mainly
because closing the window apparently destroys it, and then WM_USER
can't be handled anymore - which means the playloop has no way to
wakeup the GUI thread. It seems you can't really win here... maybe
there's a better way to have a thread receive messages with and
without a window, but I didn't find one yet.
Dragging the window (by clicking into the middle of it) behaves
strangely in wine, but didn't before the change. Reason unknown.
win32 does not provide a proper per-window context pointer. Although it
does allow passing a user-chosen value to WM_CREATE/WM_NCCREATE, this
is not enough - the first message doesn't even have to be WM_NCCREATE.
This gets us in trouble later on, so go the easy route and just use a
TLS variable.
__thread is gcc specific, but Windows is a very "special" platform
anyway. We support only MinGW and Cygwin on it, so who cares. (C11
standardizes __thread as _Thread_local; we can use that later.)
This shouldn't change anything. But it's worth making this explicit,
since it's very subtle and unintuitive: if the X parameter is the
magic value CW_USEDEFAULT, then the Y parameter is used as nCmdShow
parameter to ShowWindow(). And in our case, this is SW_HIDE (0),
because we want to create a hidden window.
This looked a bit overcomplicated. We don't care about the window
position (it should always be 0/0, unless the parent program moved it,
which it shouldn't). We don't care about the global on-screen position.
Also, we will just retrieve a WM_SIZE message if our window is resized,
and we don't need to update it manually.
The only thing we have to do is making sure our window fills the parent
window completely.
CS_OWNDC will make GetDC() always return the same HDC. This might
become a problem when OpenGL rendering and window management are
on different threads. Although I'm not too sure about this; our
code never requests a HDC outside of the OpenGL backend, and it
depends on whether win32 will internally request DCs. But in any
case, this seems to be cleaner.
Move the GL pixelformat setup code to gl_w32.c, where it's actually
needed. This also fixes that SetPixelFormat() should be called only
once, and not every time video params change.
These mostly describe self-explanatory things, and fail to explain
actually tricky things. Which means you just waste your time reading
this, and have to figure it out from the code anyway.
Preparation for moving win32 windowing to a separate thread.
The codesize is reduced a bit, because some small functions are
inlined, which reduces noise.
The main change is that now most functions use the private struct
directly, instead of accessing it indirectly through vo->w32.
Accesses to vo are minimalized.
The final goal is adding some sort of new windowing backend API. It
would be cleaner to use that as context pointer for all functions
(like struct vo was previously used), but since this is work in
progress, we just go with this commit.
This replaces translate_key_input with a solution that gives mpv more
control over how keyboard input is converted to unicode. As a result:
- Key up/down events are generated the same way for all keys.
- Dead keys generate their base character instead of being combined with
the following character.
- Many Ctrl and Ctrl+Alt key combinations that were previously broken
are fixed, since it's possible to discover the base keys.
- AltGr doesn't produce special characters when mp_input_use_alt_gr is
false.
This also fixes some logic to do with detecting AltGr and adds proper
UTF-16 decoding.
The window doesn't recieve a WM_LBUTTONUP message after it's dragged,
probably because it's swallowed by the modal loop. To stop the button
from sticking, release it manually when the drag is complete.
Mouse buttons can get stuck down if the button is pressed inside the
video window and released outside. Avoid this by capturing mouse input
when a button is pressed.
This is a bit of a hack, but in order to prevent TranslateMessage from
seeing WM_KEYDOWN messages that we already know how to decode, move the
decoding logic to the event loop. This should fix#476, since it stops
the generation of extraneous WM_CHAR messages that were triggering more
than one action on keydown.
Marcin Kurczewski
Avi Halachmi (:avih)
James Ross-Gowan
wm4
torque
Kevin Mitchell