| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | |
|
| |
|
|
| |
Fixes #503
|
| |
|
| |
Makes ricers happy.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this change, Cocoa state was accessed from both the VO and the
Cocoa main thread. This was probably not a good idea. There was some
locking as well as implicit synchronization using the dispatch
mechanism, but it wasn't watertight.
Change this completely. Now Cocoa things are always accessed from the
main thread only. The old mutex falls away, as well as the
vo_cocoa_set_current_context() function, which implicitly used the lock
to coordinate VO accesses. With the new code, the VO thread generally
has to wait for the main thread, while the main thread never waits for
the VO and rarely accesses it. Fortunately, this is rather straight
forward, and most of this is achieved by making vo_cocoa_control() run
on the main thread. The logic of the code does generally not change.
Some aspects are trickier. Apparently we can't access the
NSOpenGLContext from the VO thread, because this object is not thread-
safe. We use some CGLContextObj functions instead, such as for making
the context current and swapping the buffers.
|
| |
|
|
|
|
|
|
|
|
|
| |
Interrupt video timing. This means the Cocoa event loop does not have
to up to 2 video frame durations until redrawing the frame finally has
finished.
We abuse the VO event flags for this. Eventually this should use
wait_vo() or so in the video timing wait function, but for now the
interaction this would require with the code of other VOs/backends
would cause too much of a mess.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of requiring a complicated mechanism to share the entire OpenGL
and renderer state between VO and Cocoa thread just to do the redrawing
during live-resize on the Cocoa thread, let the Cocoa thread wait on the
VO thread. This wil allow some major simplifications and cleanups in the
future.
One problem with this is that it can enter a deadlock whenever the VO
tries to sync with the Cocoa thread. To deal with this, the Cocoa thread
waits with a timeout. This can probably be improved later, though in
general this situation can always happen, unless the Cocoa thread waits
in a reentrant way.
Some other details aren't completely clean either. For example,
pending_events should be accessed atomically. This will also be fixed
later.
|
| |
|
|
|
| |
The first one (for VOCTRL_GET_DISPLAY_FPS) could have led to undefined
behavior if the FPS was unknown. The second is for general symmetry.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should fix some crashes due to dangling pointers.
The problem was that with_cocoa_lock_on_main_thread() is asynchronous.
It will not wait until it is finished. In the uninit case, this means
the VO could be deallocated and destroyed while cocoa was still running
uninit code.
So simply wait until it is done by using dispatch_sync(). There were
concerns that this could introduce a deadlock by the main thread trying
to wait for something on the VO thread. But from what I can see, this
never happens, and even if it does, it would crash anyway since the VO
is already gone.
One remaining worry is the video_resize_redraw_callback. From what I can
see, it still can mess things up, and will need a more elaborate fix.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This unbreaks compiling command line player and libmpv at the same
time. The problem was that doing so silently disabled the OSX
application thing - but the command line player can not use the
vo_opengl Cocoa backend without it.
The OSX application code is basically dead in libmpv, but it's not
that much code anyway.
If you want a mpv binary that does not create an OSX application
singleton (and creates a menu etc.), you must disable cocoa
completely, as cocoa can't be used anyway in this case.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With --idle --force-window, or when started from the bundle, the cocoa
code dropped the first frame. This resulted in a black frame on start
sometimes.
The reason was that the live resizing/redrawing code was invoked, which
simply set skip_swap_buffer to false, blocking redrawing whatever was
going to be rendered next. Normally this is done so that the following
works:
1. vo_opengl draw a frame, releases GL lock
2. live resizing kicks in, redraw the frame
3. vo_opengl wants to call SwapBuffers, drawing a stale buffer
overwritten by the live resizing code
This is solved by setting skip_swap_buffer in 2., and querying it in 3.
Fix this by resetting the skip_swap_buffer at a known good point: when
vo_opengl starts drawing a new frame.
The start_frame function returns bool, so that it can be merged with
is_active in a following commit.
|
| |
|
|
| |
Fixes #1686
|
| | |
|
| |
|
|
| |
Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Some UI elements in OS X – like Launchpad and Dock folders – are implemented
using borderless windows in background demonized applications.
When we use these elements, mpv doesn't stop to be the active application, but
the mpv window leaves keyWindow state while we use the OS controls.
This commit just keeps track of window state to update the cursor visibility
accordingly.
Fixes #513
|
| |
|
|
|
|
| |
Make MpvEventsView -signalMousePosition a public method so it can be
called without a compiler warning. Previously, the mouse position would
be reported as (0,0) until the cursor was moved.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Always keep around our private state and destroy it when we are really done in
the async uninit callback.
Fixes #1657
|
| |
|
|
|
|
|
|
|
| |
This will be pretty useful to let mpv automatically change VO parameters based
on ambient lighting conditions.
The conversion code and polinomial equation from Apple LMU values to Lux is
taken from Firefox: their license, MPL is GPL compatible and allows
relicensing to GPL (MPL is more liberal).
|
| |
|
|
|
|
| |
Just use makeFirstResponder on the mpv events view from client code
if you need the built in keyboard events (this is easier for dealing with view
nesting).
|
| |
|
|
|
|
|
|
| |
Apparently CoreGraphics reports the actual refresh rate. DisplayLink can also
query the nominal refresh rate of the display so we use that as fallback
instead of the fugly 60fps hardcode added in aeb1fca0d.
Props to people on https://github.com/glfw/glfw/issues/137
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Comment explains why I have been so doubtful at adding this. The Apple docs
say CGDisplayModeGetRefreshRate is supposed to work only for CRTs, but it
doesn't, and actually works for LCD TVs connected over HDMI and external
displays (at least that's what I'm told, I don't have the hardware to test).
Maybe Apple docs are incorrect.
Since AFAIK Apple doesn't want to give us a better API – maybe in the fear we
might be able to actually write some useful software instead of "apps" –
I decided not to care as well and commit this.
|
| |
|
|
|
| |
Remove the "PATH" bit, because VOCTRL_GET_ICC_PROFILE returns an in-
memory profile, and not a path. (This was changed a while ago.)
|
| |
|
|
| |
Fixes #1483, if it even compiles.
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously we just forced loading a profile from file, but that has poor
integration for querying the OS / display server for an ICC profile, and
generating profiles on the fly (which we might use in the future for creating
preset 3dluts).
Also changed the previous icc-profile-auto code to use this mechanism, and
moved gl_lcms to be an opaque type with state instead of just providing pure
functions.
|
| |
|
|
|
|
|
|
| |
This is only needed for switching video track with `_`, since Cocoa
automatically handles cleaning up the application's presentation options when
quitting the process.
Fixes #1399
|
| | |
|
| |
|
|
|
|
|
| |
This used to work correctly without the call to displayIfNeeded. I think this
may only be needed for Yosemite.
Fixes #1330
|
| |
|
|
|
|
| |
fixes #1323
Doesn't leak unless we switch video tracks on and off while in fullscreen.
|
| | |
|
| |
|
|
|
| |
Previously when using the bundle we used a custom bizarro thing to wait for
events. Just use `--idle` and greatly simplify the code.
|
| |
|
| |
/cc @mpv-player/stable
|
| |
|
|
| |
fixes #635
|
| |
|
|
|
| |
This fixes the very annoying glitch where the black bars disappear for
a single frame when going fullscreen.
|
| |
|
|
| |
Removes the dependency from the Cocoa backend in case we are not using
it but still wanna use VDA GL introp.
|
| |
|
| |
fixes #1302
|
| | |
|
| |
|
|
|
|
| |
NSDisableScreenUpdates came to hunt me in the end and when mpv was paused, it
did wait for a frame that never came (because of interaction with the live
resizing code)!
|
| |
|
|
| |
Use TOOLS/osxbundle.py instead. It's just better and less hacky.
|
| | |
|
| |
|
|
|
| |
The code was lacking a -removeFromSuperview call which resulted in a leak on
our part if the parent view in the client was not released.
|
| |
|
|
|
|
|
|
| |
Apparently if resizing a NSWindow from a secondary thread Cocoa will
automatically protect itself using NSViewHierarchyLock and in our case,
cause a deadlock.
Fixes #1210
|
| |
|
|
|
|
|
| |
After removing synchronous libdispatch calls, this looks like it doesn't
deadlock anymore. I also experimented with pthread_mutex_trylock liek wm4
suggested, but it leads to some annoying black flickering. I will fallback to
that only if some new deadlocks are discovered.
|
| |
|
|
| |
This reverts commit a0ac8b6331d345748d415cf71affbe7a90e336a6.
|
| |
|
|
|
| |
Previously we didn't report events to the core, but still prevented the events
to travel on the responder chain.
|
wm4
Rodger Combs
Stefano Pigozzi
Jaime Marquínez Ferrándiz
torque