summaryrefslogtreecommitdiffstats
path: root/video/out/cocoa_common.m
Commit message (Collapse)AuthorAgeFilesLines
* Revert "cocoa: re-enable double buffering"James Ross-Gowan2017-09-221-2/+0
| | | | | | | | Enabling double buffering fixed some graphical glitches when entering fullscreen, but it also caused a fullscreen performance regression. We decided that the glitches were preferable to the performance regression. This reverts commit cee764849e4fe22b00fb3f31838a63906e2e0d54.
* cocoa: re-enable double bufferingJames Ross-Gowan2017-09-211-0/+2
| | | | | | | | | This causes a performance regression on 10.11 and newer, but the single buffered method was broken and could cause partially rendered frames to be presented to the screen. This reverts 9f30cd8292b4b7bfe5d7db29fe31a07cc76dec2c and e543853a7ff0ab4dcd4ccaf06c448013fd41c03a.
* input: merge mouse wheel and axis keycodesJames Ross-Gowan2017-09-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | Mouse wheel bindings have always been a cause of user confusion. Previously, on Wayland and macOS, precise touchpads would generate AXIS keycodes and notched mouse wheels would generate mouse button keycodes. On Windows, both types of device would generate AXIS keycodes and on X11, both types of device would generate mouse button keycodes. This made it pretty difficult for users to modify their mouse-wheel bindings, since it differed between platforms and in some cases, between devices. To make it more confusing, the keycodes used on Windows were changed in 18a45a42d524 without a deprecation period or adequate communication to users. This change aims to make mouse wheel binds less confusing. Both the mouse button and AXIS keycodes are now deprecated aliases of the new WHEEL keycodes. This will technically break input configs on Wayland and macOS that assign different commands to precise and non-precise scroll events, but this is probably uncommon (if anyone does it at all) and I think it's a fair tradeoff for finally fixing mouse wheel-related confusion on other platforms.
* osx: code cleanups and cosmetic fixesAkemi2017-08-181-2/+0
| | | | silence build warnings, clean up code style and remove unused code.
* cocoa: add an option to disable the native macOS fullscreenAkemi2017-08-061-2/+7
| | | | Fixes #4014
* osx: change license of OSX and cocoa files to LGPLwm42017-06-241-7/+7
| | | | All authors of the current code have agreed.
* cocoa: properly unhide Dock when quitting during System fs animationAkemi2017-05-191-0/+52
| | | | | | | | when quitting mpv during the System fullscreen animation cocoa can't reset some flags properly and won't reset the Dock hiding behaviour to it's previous state. Fixes #4400
* cocoa: fix retrieval of unfs window size while animatingAkemi2017-04-171-1/+2
| | | | | | | | | | | due to the System inherent fullscreen animation the option and the actual fullscreen state can be out of sync, leading to a wrongly reported unfs window size in the time of the animation. just always fall back to the window size, we keep track of, when we either are in fullscreen or are currently switching to it. Fixes #4323
* cocoa: fix retrieval of unfs window sizeAkemi2017-03-261-3/+11
| | | | | | | | | | | | | | there are two minor bugs. mpv could try to retrieve the size when in fullscreen and would get the fullscreen size. to fix that we keep track of the window size before going into fullscreen. the second small bug is when using HiDPI resolution and the --hidpi-window-scale option. we actually want the OSD to show the proper window scale depending on the hidpi settings. before when resizing the window to double the size it could show "window-scale: 1.0" or "window-scale: 0.5" when resizing to normal size. now it considers the backing scale factor and the hidpi option to return a logical correct window size.
* osx: fix key input in certain circumstancesAkemi2017-03-261-8/+0
| | | | | | | | | | | | | for a reason i can just assume some key events can vanish from the event chain and mpv seems unresponsive. after quite some testing i could confirm that the events are present at the first entry point of the event chain, the sendEvent method of the Application, and that they vanish at a point afterwards. now we use that entry point to grab keyDown and keyUp events. we also stop propagating those key events to prevent the no key input' error sound. if we ever need the key events somewhere down the event chain we need to start propagating them again. though this is not necessary currently.
* cocoa: fix autofit options on HiDPI resolutions without HiDPI scalingAkemi2017-03-091-33/+15
| | | | Fixes #4194
* cocoa: fix segfault in certain circumstancesAkemi2017-02-271-0/+4
| | | | | | | | | | | | | | i falsely assumed that the windowDidChangeScreen was meant to report ‘physical’ screen changes but was wondering why it triggers on other events too. it actually is a event that informs us when anything referenced by our current NSScreen is changed. even when something referenced in the NSScreen changed the old and new NSScreen are still equal if the physical screen didn’t change. with that my previous optimisation broke some cases where the physical screen didn’t change but things it referenced did, leading to a segfault when theses were accessed. to keep the optimisation we will always update our internal NSScreen reference but the rest only when the physical screen was changed.
* cocoa: fix dragging out of focus windowAkemi2017-02-211-5/+21
| | | | | | | | | | 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
* cocoa: only report mouse movements when window is not being draggedAkemi2017-02-201-1/+13
| | | | | | 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.
* cocoa: make window draggable on initAkemi2017-02-201-0/+2
| | | | | | 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.
* cocoa: simplify the cursor hiding codeAkemi2017-02-191-35/+15
| | | | | | | | | | 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.
* cocoa: refactor mouse events and cursor visibilityAkemi2017-02-161-27/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* cocoa: fix black edges on live resizeAkemi2017-02-131-20/+34
| | | | | | | | 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.
* cocoa: add --ontop-level option for modifying ontop window levelAkemi2017-02-131-6/+13
| | | | | | | | | | 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
* 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 thr