summaryrefslogtreecommitdiffstats
path: root/video/out/cocoa_common.m
Commit message (Collapse)AuthorAgeFilesLines
* cocoa: fix color profile retrievalAkemi2017-02-021-0/+1
| | | | | | | | 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.
* cocoa: optimise screen event handlingAkemi2017-02-021-4/+11
| | | | | | | | | | | | | | | | 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.
* cocoa: fix displaylink refresh rate retrievalAkemi2017-02-021-23/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* cocoa: fix unwanted behavior with window level other than the defaultAkemi2017-01-291-2/+4
| | | | | | | | | | 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
* cocoa: don't init displaylink on reconfigAkemi2017-01-191-1/+1
| | | | | | | | | | | 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
* cocoa: move updateBorder method to the protocolAkemi2017-01-191-2/+3
| | | | | | 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.
* cocoa: don't change Space on quit in fullscreenAkemi2017-01-111-6/+10
| | | | | | | circumvent undefined behavior when quitting in fullscreen. Fixes #3957
* cocoa: rate limit video outputAkemi2017-01-111-14/+51
| | | | | | | | | | | | the display refresh rate can't be estimated correctly in some cases and just increases till it turns off display-resample. cases are off-screen rendering (different space), mpv being completely hidden behind another window or the mission control view. this utilise the unused displaylink callback to limit the refresh rate to the actual display refresh rate.
* cocoa: add border cyclingAkemi2017-01-111-0/+16
| | | | Fixes #2430
* cocoa: fix handling of geometry optionAkemi2017-01-111-7/+27
| | | | | | | | | | | | | | This flips the y-coordinate to be consistent with other platforms and the manual. furthermore it fixes an unwanted behaviour of the cocoa convertRectFromBacking method, where the x- and y-coordinate was divided by the same factor as the width and height instead of placing the new scaled rectangle at the same relative position as the original unscaled rectangle, by manually calculating the new position. Fixes #3867
* cocoa: cosmetic fixesAkemi2016-12-161-5/+10
|
* cocoa: fullscreen refactoringAkemi2016-12-151-165/+115
| | | | | | | | | | this replaces the old fullscreen with the native macOS fullscreen. additional the --fs-black-out-screens was removed since the new API doesn't support it in a way the old one did. it can possibly be re-added if done manually. Fixes #2857 #3272 #1352 #2062 #3864
* cocoa: option to scale window by HiDPI scale factorAkemi2016-11-111-2/+9
| | | | | | | | | | Deactivating this options makes it possible to circumvent the default OS X behavior of using points. Windows on HiDPI resolutions won't open in double the size anymore and videos are display in their native resolution when windowed. Fixes #3716
* cocoa: add glFlush() to cocoa backendAkemi2016-10-061-2/+0
| | | | | | | | | | | | The glFlush() call was made optional recently since it's not needed in most cases. On OSX though this is needed since we removed kCGLPFADoubleBuffer from the context creation, so the glFlush() call was added to the cocoa backend only. The CGLFlushDrawable() call can be safely removed since it only does something when a double buffered context is used. Also fixes a small typo. Fixes #3627.
* cocoa: fix macOS 10.12 deprecation warningsAkemi2016-09-221-3/+3
|
* osdep: rename atomics.h to atomic.hwm42016-09-071-1/+1
| | | | | The standard header is stdatomic.h, so the extra "s" freaks me out every time I look at it.
* vo: change messy handling of fullscreen and other flagswm42016-08-301-2/+0
| | | | | | | | | | | | | | Before this commit, all VOs had to toggle the option flag themselves, now command.c does it. I can't really comprehend why it required every VO to do this manually. Maybe it was for rejecting the property/option change if the VO didn't support a specific capability. But then it could have checked the VOCTRL result. In any case, I don't care, and successfully changing the property without doing anything (With some VOs) is fine too. Many things work this way now, and it's simpler overall. This change will be useful for cleaning up VO option handling.
* cocoa: remove unused icc profile variablesAkemi2016-07-211-2/+0
|
* cocoa: update screen fps only if necessaryAkemi2016-07-211-1/+3
| | | | | we don't need to update the display refresh rate when going fullscreen or updating the colour profile
* 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