summaryrefslogtreecommitdiffstats
path: root/video/out/cocoa_common.m
Commit message (Collapse)AuthorAgeFilesLines
* cocoa: fix display refresh rate retrieval on multi monitor setupsAkemi2016-06-181-4/+12
| | | | | | | | | | | | | | | | | | 1. this basically reverts commit de4c74e5a4a996e8ff431c8f33a32c4b580be203. even with CVDisplayLinkCreateWithActiveCGDisplays and CVDisplayLinkSetCurrentCGDisplayFromOpenGLContext we still have to explicitly set the current display ID, otherwise it will just always choose the display with the lowest refresh rate. another weird thing is, we still have to set the display ID another time with CVDisplayLinkSetCurrentCGDisplay after the link was started. otherwise the display period is 0 and the fallback will be used. if we ever use the callback method for something useful it's probably better to use CVDisplayLinkCreateWithActiveCGDisplays since we will need to keep the display link around instead of releasing it at the end. in that case we have to call CVDisplayLinkSetCurrentCGDisplay two times, once before and once after LinkStart. 2. add windowDidChangeScreen delegate to update the display refresh rate when mpv is moved to a different screen.
* cocoa: fix actual display refresh rate retrievalAkemi2016-06-181-3/+18
| | | | | | | | | | | | | We have two problems here. 1. CVDisplayLinkGetActualOutputVideoRefreshPeriod, like the name suggests, returns a frame period and not a refresh rate. using this as screen_fps just leads to a slideshow. why didn't this break video playback on OS X completely? the answer to this leads us to the second problem. 2. it seems that CVDisplayLinkGetActualOutputVideoRefreshPeriod always returns 0 if used without CVDisplayLinkSetOutputCallback and hence always fell back to CVDisplayLinkGetNominalOutputVideoRefreshPeriod. adding a callback to CVDisplayLink solves this problem. the callback function at this moment doesn't do anything but could possibly used in the future.
* cocoa: use displaylink without manually tracking the display idStefano Pigozzi2016-06-111-5/+6
| | | | | Maybe it partially helps with #2392 (on dual display setups). Either way, it makes the code simpler.
* cocoa: get fps only from dislaylinkStefano Pigozzi2016-01-141-8/+9
| | | | | In my tests, CGDisplayModeGetRefreshRate returns 24.0 even though the nominal one is set to 24000/1001. This is obviously not good for video.
* cocoa: add an observer for screenmode changeStefano Pigozzi2016-01-141-0/+26
|
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* vo_opengl: cocoa: implement alpha window supportwm42015-12-191-0/+6
| | | | | With --vo=opengl:alpha=yes, the Cocoa backend will now render alpha video without background.
* cocoa: fix recent regressionwm42015-12-071-4/+6
| | | | | | | Commit 9db50c67 changed it so that the window title can now be a NULL string. Completely untested. Probably fixes #2570.
* vo: get rid of vo_get_window_title()wm42015-12-061-5/+12
| | | | | | | | | | | It always was a weird artifact - VOCTRLs are meant _not_ to require special handling in the code that passes them through (like in vo.c). Removing it is also interesting to further reduce the dependency of backends on struct vo. Just get rid of it. Removing it is somewhat inconvenient, because in many situations the UI window is created after the first VOCTRL_UPDATE_WINDOW_TITLE. This means these backends have to store it in a new field in their own context.
* vo: remove VOCTRL_GET_RECENT_FLIP_TIMEwm42015-11-231-2/+0
| | | | | | | | | | | It doesn't have any real purpose anymore. Up until now, it was still implemented by vo_wayland, but since we changed how the frame callbacks work, even that appears to be pointless. Originally, the plan was to somehow extend this mechanism to all backends and to magically fix frame scheduling, but since we can't hope for proper mechanisms even on wayland, this idea looks way less interesting.
* cocoa: set application policy before creating windowwm42015-10-111-5/+4
| | | | | | | | | | | | This fixes a regression since commit f4d62da8. The original code run vo_cocoa_config_window() once without creating the window, which had the effect that the last part of the function was run at least once before the actual window was created. Fix the regression by moving it to before the window is created. The regression itself is hard to describe. One test case: start mpv from a fullscreened terminal window. It should switch to another desktop, with the mpv window visible. This didn't happen anymore.
* vo_opengl: cocoa: switch to new internal APIwm42015-10-011-4/+3
|
* cocoa: hide cursor using a blank image instead of a system-wide APIRodger Combs2015-08-111-4/+14
| | | | Fixes #503
* cocoa: don't load hardcoded icon if running from bundleStefano Pigozzi2015-05-251-0/+3
| | | Makes ricers happy.
* cocoa: redo synchronizationwm42015-05-131-155/+147
| | | | | | | | | | | | | | | | | | | | | 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.
* cocoa: make live-resizing as fast as beforewm42015-05-121-1/+3
| | | | | | | | | | | 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.
* cocoa: handle live-resizing differentlywm42015-05-121-31/+41
| | | | | | | | | | | | | | | | | | 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.
* cocoa: add missing break statements in switchwm42015-05-111-0/+2
| | | | | 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.
* cocoa: remove unused macrowm42015-05-111-1/+0
|
* cocoa: remove an unused parameterwm42015-05-061-1/+1
|
* cocoa: lock cocoa main thread on uninitwm42015-05-061-1/+9
| | | | | | | | | | | | | | | | | | 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.
* cocoa: always compile OSX application code with cocoawm42015-05-021-6/+2
| | | | | | | | | | | | | | 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.
* cocoa: don't accidentally drop initial screen drawingwm42015-05-011-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* cocoa: signal VO_EVENT_WIN_STATE on fps changeStefano Pigozzi2015-03-141-0/+2
| | | | Fixes #1686
* cocoa: fix minimized state getterStefano Pigozzi2015-03-091-5/+2
|
* cocoa: support the "window-minimized" propertyJaime Marquínez Ferrándiz2015-03-081-0/+22
| | | | Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
* cocoa: fix autohide in fullscreenStefano Pigozzi2015-03-081-1/+21
|
* cocoa: fix mouse hiding with launchpad and dock foldersStefano Pigozzi2015-03-081-1/+7
| | | | | | | | | | | | 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
* cocoa: update mouse coordinates when window is initialized.torque2015-03-071-1/+3
| | | | | | 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.
* cocoa: don't uninit light sensor if not presentStefano Pigozzi2015-03-071-2/+4
|
* cocoa: remove possible use after freeStefano Pigozzi2015-03-071-5/+5
|
* cocoa: fix some crashes caused by async uninitStefano Pigozzi2015-03-071-31/+15
| | | | | | | Always keep around our private state and destroy it when we are really done in the async uninit callback. Fixes #1657
* cocoa: add support for querying ambient lightingStefano Pigozzi2015-03-041-0/+94
| | | | | | | | | 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).
* cocoa: remove the setNextKeyView hackStefano Pigozzi2015-02-281-4/+0
| | | | | | 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).
* cocoa: improve refresh rate fallback codeStefano Pigozzi2015-02-031-9/+14
| | | | | | | | 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
* cocoa: automatically fetch display-fps from the monitorStefano Pigozzi2015-02-031-0/+26
| | | | | | | | | | | | 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.
* video/out: cosmetics: rename VO_EVENT_ICC_PROFILE_PATH_CHANGEDwm42015-01-261-3/+3
| | | | | Remove the "PATH" bit, because VOCTRL_GET_ICC_PROFILE returns an in- memory profile, and not a path. (This was changed a while ago.)
* cocoa: fix fullscreen handlingwm42015-01-171-2/+3
| | | | Fixes #1483, if it even compiles.
* command: unify handling of fullscreen and other VO flagswm42015-01-161-0/+2
| | | | | | | | 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.
* cocoa: don't set application icon in libmpvStefano Pigozzi2015-01-161-2/+4
|
* vo_opengl: add support for in memory icc profilesStefano Pigozzi2015-01-071-111/+11
| | | | | | | | | | | 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.
* cocoa: fix uninitialization while in fullscreenStefano Pigozzi2015-01-011-2/+23
| | | | | | | | 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
* cocoa: move the gl function loader to gl_cocoa.cStefano Pigozzi2014-12-281-14/+0
|
* cocoa: mark window for redraw after title changeStefano Pigozzi2014-12-201-1/+3
| | | | | | | This used to work correctly without the call to displayIfNeeded. I think this may only be needed for Yosemite. Fixes #1330
* cocoa: fix crashStefano Pigozzi2014-12-081-5/+0
| | | | | | fixes #1323 Doesn't leak unless we switch video tracks on and off while in fullscreen.
* cocoa: fix view leak in uninit when fullscreenStefano Pigozzi2014-12-061-1/+9
|
* cocoa: use --idle when running inside bundleStefano Pigozzi2014-12-061-4/+1
| | | | | Previously when using the bundle we used a custom bizarro thing to wait for events. Just use `--idle` and greatly simplify the code.
* cocoa: don't change app activation policy in libmpvStefano Pigozzi2014-12-061-3/+4
| | | /cc @mpv-player/stable
* cocoa: don't create Dock icon for audio only filesStefano Pigozzi2014-12-051-0/+21
| | | | fixes #635
* cocoa: don't async redraw when waiting for VO redrawStefano Pigozzi2014-12-041-1/+3
| | | | | This fixes the very annoying glitch where the black bars disappear for a single frame when going fullscreen.
* vda: use implicit current GL contextStefano Pigozzi2014-12-031-11/+0
| | | | Removes the dependency from the Cocoa backend in case we are not using it but still wanna use VDA GL introp.
* cocoa: allow to black out other display when going fsStefano Pigozzi2014-12-011-0/+5
| | | fixes #1302
* cocoa: don’t hand over view memory ownership to libmpv clientsStefano Pigozzi2014-11-251-1/+1
|
* cocoa: fix fullscreen delay when pausedStefano Pigozzi2014-11-011-2/+2
| | | | | | 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)!
* build: remove bundle support from wafStefano Pigozzi2014-11-011-0/+1
| | | | Use TOOLS/osxbundle.py instead. It's just better and less hacky.
* cocoa: fix small leakStefano Pigozzi2014-10-271-0/+1
|
* libmpv: cocoa: fix view leak on uninitStefano Pigozzi2014-10-271-4/+6
| | | | | 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.
* cocoa: perform VOCTRL_SET_UNFS_WINDOW_SIZE asyncronouslyStefano Pigozzi2014-10-241-3/+6
| | | | | | | | 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
* cocoa: reintroduce async resizeStefano Pigozzi2014-10-181-7/+39
| | | | | | | 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.
* Revert "cocoa: perform init and uninit synchronously"Stefano Pigozzi2014-10-181-1/+3
| | | | This reverts commit a0ac8b6331d345748d415cf71affbe7a90e336a6.
* cocoa: allow mouse events to bubble up with no-input-cursorStefano Pigozzi2014-10-171-10/+13
| | | | | Previously we didn't report events to the core, but still prevented the events to travel on the responder chain.
* cocoa: perform init and uninit synchronouslyStefano Pigozzi2014-10-161-3/+1
| | | | | This is slightly safer and without the resize redraw, should not cause any deadlock.
* libmpv/cocoa: allow clients to use mpv event systemStefano Pigozzi2014-10-121-25/+27
| | | | | | | | | | This allows mpv's view to take key and send events to mpv's core. To set key status correctly, clients must call -[NSWindow selectNextKeyView:] during reconfig on the main thread. All is 'documented' in the cocoabasic example. If someone knows a better way to handle giving key to the embedded view, let me know!
* cocoa: post keydown and keyup events without event monitorStefano Pigozzi2014-10-091-0/+5
| | | | | Our code worked under the assumption that the event monitor is always active and we did remove the keydown and keyup overrides from our cocoa view.
*