fffab30 introduced a small regression where the cursor couldn't be
unhidden after refocusing. the problem is that no mouseUp event was
reported in our events_view. work around this with a separate event
monitor. this also fixes another regression when the window is being
dragged from the title bar.
#4174
This fixes a race condition created by the previous commit, and possibly
others. Sometimes interpolated frames weren't redrawn as uninterpolated
ones.
The problem is that redrawing/drawing a frame can't reset the VO
want_redraw flags, because logically these have to happen after the core
acknowledged and explicitly reissued a redraw. The core needs to be
involved because the OSD text and drawings could depend on the playback
or window state.
Change it such that it always goes through the core.
Also, VOs inconsistently called vo_wakeup() when setting want_redraw,
which is also taken care of by this commit.
When pausing, we sent BOCTRL_PAUSE and VOCTRL_RESTORE_SCREENSAVER. These
essentially wait until the video frame has been rendered. This is a
problem with the opengl-cb, if GL rendering is done in the same thread
as libmpv uses. Unfortunately, it's allowed to use opengl-cb this way.
Logically speaking, it's a deadlock situation, which is resolved with a
timeout. This can lead to quite ugly effects, like the on-pause frame
not being rendered until the timeout has passed. It has been interpreted
as video continuing to play.
Resolve this by simply not blocking on pause. Make the screensaver
controls async, and handle sending VOCTRL_PAUSE in the VO thread.
(All this could be avoided by redoing the internal VO API.)
Also see #4152.
even though the mouse doesn’t move relative to the window itself, when
the window is being dragged, some outliers are still reported and
trigger the OSC.
fixes the case when mpv is opened and the cursor is within the window
bounds without moving the mouse. previously the window could only be
dragged around after the first mouse movement.
This was a hack to let libmpv API users pass a d3d device to mpv. It's
not needed anymore for 2 reasons:
1. ANGLE does not have this problem
2. Even native GL via nVidia (where this failed) seems to not require
this anymore
even before the recent refactor the cursor was hidden when moving it to
the top of the screen in fullscreen and placing it on top of the now
visible menu bar.
we need to know when the menu bar is hidden so we don’t create a
‘dead zone’ at the top of the screen where the cursor can’t be hidden.
to determine when the menu bar is visible, and with that the title bar,
we get the height of the menu bar. the height is always 0 when hidden.
furthermore there is no way to get the title bar directly and with that
its height. so we calculate the frame rect of a NSWindowStyleMaskTitled
window from a CGRectZero content frame. the resulting height is the
height of a title bar.
with that we can exclude the top area for the cursor hiding and can be
certain when the menu bar is not hidden.
the cursor couldn’t be hidden when the cursor was at the same position
as the Dock, even if the cursor was next to it. this is especially
annoying in fullscreen since the Dock isn’t actually hidden but is still
reported as being visible. this basically made the part of the screen,
where the Dock resides, a ‘dead zone’. so instead of using the
visibleFrame we will just use the normal frame. there is no problem at
the top area of the screen, since a window can’t be placed above the
menu bar and in fullscreen the menu bar is always reported as not being
on screen.
i suspect this was done so the cursor wasn’t hidden when the it was
placed above the Dock when windowed. with the recent refactor this is
not needed any more.
we can simplify the code because we don't need to change the bool
pointer we were given by the VOCTRL_SET_CURSOR_VISIBILITY event. i
assume this was done to work around some bugs previously to the recent
cursor refactor. i kept that because i thought it was necessary, which
wasn't in the end. after the refactor it only caused some weirdnesses i
tried to work around. without it we can get rid of some special cases
and simplify the code quite a bit.
Implements --hwdec=videotoolbox on iOS. Similar to hwdec_osx.c, but
using CVPixelBuffer APIs available on iOS instead of the equivalent
IOSurface APIs in macOS.
We can drop the custom table.
For some reason, the interop does not accept GL_RGB_RAW_422_APPLE as
internal format for GL_RGB_422_APPLE, so switch the format table to use
GL_RGB (this way both interop and real textures work the same).
Another victim of the apparent requirement of exactly matching texture
formats is kCVPixelFormatType_32BGRA. vo_opengl wants to handle this as
normal RGBA texture, with a swizzle applied in the shader.
CGLTexImageIOSurface2D() rejects this, because it wants the exact
internal format. Just drop the format, because it's useless anyway.
(Maybe this is a bit too fragile...)
All supported pixel formats have a specific "mapping" of CPU data to
textures. This function determines the number and the formats of these
textures. Moving it to a helper will be useful for some hardware decode
interop backends, since they all need similar things.
GL_LUMINANCE_ALPHA is the only reason why per-plane swizzles exist.
Remove per-plane swizzles (again), and regrettably handle them as
special cases (again). Carry along the logical texture format (called
gl_format in some parts of the code, including the new one).
We also don't need a use_integer flag, since the new gl_format member
implies whether it's an integer texture. (Yes, the there are separate
logical GL formats for integer textures. This aspect of the OpenGL API
is hysteric at best.)
This should change nothing about actual rendering logic and GL API
usage.
Originally, there was probably some sort of intention to restrict it to
formats supported by the interop, or something. But in the end it was
overcomplicated nonsense.
In the future, we could use mp_hwdec_ctx.supported_formats or other
mechanisms to handle this in a better way.
mp_hwdec_ctx.ctx is not set to a dummy pointer - hwdec_devices_load() is
only used to detect whether to vo_opengl interop is present, and the
common hwdec code expects that the .ctx field is not NULL.
This also changes videotoolbox-copy to use --videotoolbox-format,
instead of the FFmpeg-set default.
The code for copying a videotoolbox surface to mp_image was duplicated
(with some minor differences - I picked the hw_videotoolbox.c version,
because it was "better"). mp_imgfmt_from_cvpixelformat() is somewhat
duplicated with the vt_formats[] table, but this will be fixed in a
later commit, and moving the function to shared code is preparation.
we reported some unnecessary mouse movements and not all mouse enter
and leave events. that lead to wrongly reported activity on hover areas
like on the OSC or comparable lua scripts. sometimes menu items were
shown that shouldn't be shown or they didn't vanish because of the
missing mouse leave event.
this incorporates @torque's fix for mouse leave events that weren't
triggered during a transition, like going to fullscreen. the
tracking area was updated but the mouse never left that area because
it was never over it.
besides some known cursor visibility bugs the aforementioned changes
also revealed some other bugs that weren't reproducible before because
of the missbehavior.
known issues, in some cases the cursor doesn't show or hide properly.
for example when switching spaces, switching Apps via CMD+Tab or a
system notification. former two could be fixed while keeping our current
blank cursor approach. though the notification case couldn't. there is
no event or similar to detect a notification and the cursor visibility
couldn't be recovered in any way.
new issues, i noticed that our event view isn't initialised yet when the
first VOCTRL_SET_CURSOR_VISIBILITY event gets dispatched, which depends
on the event view to be initialised. so the mouse cursor couldn't be
hidden when mpv was opened and the cursor was within the window bounds.
this wasn't noticeable before because of various bugs and unwanted
behavior that have been fixed with this. now, in case the event view
isn't ready yet, we set the visibility at a later point when the event
view is ready and a helper flag is set.
Fixes#1817#3856#4147
this fixes a small bug with black edges on live resize, due to the
synchronisation with the DisplayLink. we just pause the DisplayLink for
the duration of the live resize. i also added some convenience functions
for reoccurring calls and simplified some DisplayLink related screen
info.
since there are different views on what ontop is, we make the ontop
window level modifiable. at the moment only support for macOS was added.
the default for macOS was changed from 'system' to 'window' since this
fixes an unwanted behaviour in fullscreen and in general causes less
issues with expected behaviour.
Fixes#2376#3974
This replaces the old backend that exclusively used EGL windowing with
one that can also use ANGLE's ability to render to directly to a
texture. The advantage of this is that it allows mpv to create the swap
chain itself and this allows mpv to use a flip-mode swap chain on a HWND
(which avoids problems with DirectComposition) and to use a longer swap
chain that has six backbuffers by default (which reportedly fixes
problems with rendering 24fps video on 24Hz monitors.)
Also, "screenshot window" should now work on DXGI 1.2 and up (Windows 8
and up.)
when the color profile was changed it used the right NSScreen but with
the old colorSpace. this was optimised out by a previous commit because
of a wrong assumption. we need to update the screen so we can get the
new colorSpace. this adds a bit of redundancy since on screen change it
will update screen pointer twice.
the problem here is that dropped files can also be treated as
NSURLPboardType instead of just NSFilenamesPboardType. the 'else if'
could never be reached and was dead code.
this basically reverts ed695ce which tried to fix multiple dropped
URLs, or rather files, and moves the filename check infront of the URL
check. the filename path can handle multiple dropped files, whereas the
URL path can only handle one dropped URL. this assumes that only one URL
can be dropped at a time. it also reverts a603543 because it's not
needed any more.
this also fixes a problem where dropped URLs from Chrome don't conform
to the NSURL class and the readObjectsForClasses method always returned
an empty URL.
Fixes#4036
this optimises two things and fix a minor bug.
1. we always updated the display refresh rate on any mode change whether
it was the current screen or not. now we only update the refresh rate
when the mode changed happened on the current screen.
2. the windowDidChangeScreen event doesn't exclusively trigger on screen
changes so we updated the display refresh rate in cases where it wasn't
needed at all. since we manually keep track of the current screen, we
can easily test if the screen really changed.
3. weirdly on initWithContentRect accessing the screen of the window
always returned the main screen instead of the screen the window is
created on. since we already use the window init method with the screen
as argument, overwrite that method instead and use the screen argument.
we are dealing with several problems here, which weren't apparent
because we always initialised a new displaylink for the display refresh
rate retrieval, previously to commit 449eb20 and bug 9490b62.
just changing the display with CVDisplayLinkSetCurrentCGDisplay
can cause inconsistent refresh rates and discontinuity in timestamps.
this can either lead to bogus values for the Actual display refresh rate
or retrieving the refresh rate of the previous display if we immediately
try to get a new value. since the Actual refresh rate is computed i
assume that it at least needs one refresh period to actual return
something useful.
furthermore when changing the screen and updating the displaylink, it
seems that the retrieved refresh rates for the screen mpv wasn't opened
on are being estimated in a sub-optimal way. as an example, when moving
my window to my second screen the Actual refresh rate was always a
constant 60Hz, even though it is supposed to fluctuate a little bit.
though if mpv was started on the secondary screen the Actual refresh
rate fluctuated around 59.94Hz like expected. in that case my primary
screen always reported a constant 60Hz instead.
for the first problem we moved the actual retrieval of the refresh rate
to the very last moment when mpv actual requests a new value and not
when the refresh rate changed. we only update the displaylink itself
when a possible refresh rate change is detected. this gives the
displaylink some time to calculate the new refresh rate. for the second
problem, instead of setting the new display we completely uninitialise
the old dislaylink and create a new one for the new screen. this gives
us properly estimated refresh rates.
additionally we also optimised the display refresh rate fallback
heuristic. it will never be 0 anymore and we prevent it from returning
bogus values with a simple threshold for the difference of the Actual
and Nominal refresh rate.
setting a window level other than NSNormalWindowLevel always sets
NSWindowCollectionBehaviorTransient, which prevents certain things to
work properly. examples are automatic switching to the active Space when
mpv is made active and (de-)miniaturizing. latter always lead to a
vanishing window.
Fixes#1757#1884
The lock was disabled recently. This commit gets rid of the dummied out
calls. The main reason for removing it is that there is no apparent need
for it anymore, and the new FFmpeg vaapi code does not use or provide
such a lock (there are some places which we cannot control and which do
vaapi API calls, like frame destructors).
It was basically inverted. Not sure how this even happened. Hopefully
it's more an "I don't know what I was doing" instead of an "I don't know
what I am doing" case.
vo_opengl used to have it as sub-option, which made it very hard to pass
down option values to backends in a generic way (even if these options
were completely backend-specific). For --opengl-dcomposition we used a
VOFLAG to deal with this. Fortunately, sub-options are gone, and we can
just add it as global option.
Move the option to context_angle.c and add it as global option. I
thought about adding a mechanism to let backends declare options, which
would get magically picked up my m_config instead of having to add them
to the global option list manually (similar to VO vo_driver.options),
but decided against this complexity just for 1 or 2 backends. Likewise,
it could have been added as a single option to avoid the boilerplate of
an option struct, but then again there are probably going to be more
angle suboptions, and it's cleaner.
Scale the window by the assumed DPI scaling factor, using 96 DPI as
base. For example, a screen that reports 192 DPI is assumed to have a
DPI scale factor 2. The window will then be created with twice the size.
For robustness reasons, we accept only integer DPI scales between 1 and
9. We also error out if the X and Y scales are very different, as this
most likely indicates a multiscreen system with botched size reporting.
I'm not sure if reading the X server's DPI is such a good idea - maybe
the Xrdb "Xft.dpi" value should be used instead. The current method
follows what xdpyinfo does.
This can be disabled with --hidpi-window-scale=no.
our constrainFrameRect prevents our window from positioning itself ontop
of the menubar, which is unwanted for a fullscreen window. this always
positioned our window vertically at -22/-23pt when going into fullscreen
because of the menubar. this bug doesn't show on newer versions of OS X
since the various flags we set force the window position. on OS X 10.9
though the fullscreen window was shifted 22pt downwards. even though
this bug doesn't show on newer OS X versions, it should still be fixed
for a possible behaviour changes in future version.
Fixes#4044
everytime we switched to a new video file a new displaylink was
initialised and started, but the old one was not stopped and released
beforehand. this lead to several displaylink callback calls per swap,
depending on how many files were switched beforehand. moving the
displaylink init call to the cocoa init functions will ever only init
one displaylink.
Fixes#4031
we are calling the method on a NSWindow object that may not respond to
that call, since its a method of MpvVideoWindow. add the method to our
protocol and rename that protocol to reflect the change.
in some circumstances cocoa isn't able to enter or exit fullscreen but
we still set window sizes and flags accordingly. this leaves us in a
hanging state between fullscreen and window. it also prevents the
toggleFullscreen method and its events to work properly afterwards. in
that state it's impossible to enter or exit this 'semi-fullscreen'.
add a proper fallback to recover from this state.
Fixes#4035
Introduce the --opengl-hwdec-interop option, which replaces
--hwdec-preload. The new option allows explicit selection of the interop
backend.
This is relatively complex, and I would have preferred not to add this,
but it's probably useful to debug certain problems. In exchange, the
"new" option documents that pretty much any but the simplest use of it
will not be forward compatible.
Replace the old code, that played games to evade thread-safety issues,
with newer thread-safe option access functions.
This also means mp_opengl_create() doesn't need to cache the hwdec
settings anymore. (They're applied in mpv_opengl_cb_init_gl() instead.)
Akemi
wm4
rr-
Aman Gupta
pavelxdd
James Ross-Gowan