| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This is slightly safer and without the resize redraw, should not cause any
deadlock.
|
|
|
|
|
|
|
|
|
|
| |
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!
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
I think this doesn't make a difference, since in Objective-C nil responds as
a NullObject, but better not depend on this crappy language feature.
|
|
|
|
|
| |
Basically add if guards on all the problematic features. I'm still thinking
about a better way to handle this, but for the time being, this will do.
|
|
|
|
| |
untested, no hardware.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
ontop, fullscreen and window title change to be precise
|
|
|
|
|
|
|
| |
This is the first of a series of commits that will change the Cocoa way in a
way that is easily embeddable inside parent views. To reach that point common
code must avoid referencing the parent NSWindow since that could be the host
application's window.
|
|
|
|
| |
credits: wm4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is just temporary code but is a good base for future work (and baby
steps are required for these changes). The 'final destination' is embedding
the video view into any NSView but that requires some more work (the mechanism
will be the same: pass the view's pointer casted to int64_t through -wid).
For instance we will need to remove as much usage of the window instance
as possible, and use nil guards where not possible. For this reason I will
remove stuff like the mission control fullscreen feature (it's a cute feature
but annoying to support and quite limited, go make your GUIs), and a way to
lookup the current screen directly from the NSView absolute coordinates
(this is needed for ICC detection mostly, and reporting back the screen to
mpv's core).
Moreover the current view.m will need to be separated into 2 views: the actual
video view that will be embedded, and a parent view that will not be embedded
and will be responsibile for tracking events.
|
|
|
|
|
|
| |
This could be dangerous because we initialize the window asynchronously and
return immediately from config, but since the OpenGL context is already
created, this seems to work correctly and doesn't cause weird deadlock cases.
|
|
|
|
|
|
| |
This doesn't look to be needed anymore. Fullscreening with both the NSView
and the NSWindow API works correctly. I guess this was forgotten in from older
code which changed presentation options directly for going fullscreen.
|
|
|
|
|
|
|
|
|
|
|
| |
At the moment when you fullscreen mpv there is a very small time interval
where the fullscreen windows is semi-transparent. Apparently whem moving the
view to another parent it's better to make Cocoa not draw anything globally.
An Apple engineer said it, so it must be correct:
http://www.cocoabuilder.com/archive/cocoa/142020-preventing-flicker-on-moving-nsview-to-different-superview.html
I know I will regret this in the future.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately using dispatch_sync for synchronization turned out to be really
bad for us. It caused a wide array of race conditions, deadlocks, etc.
Moving to a very simple mutex. It's not clear to me how to do liveresizing
with this, for now it just flickers with is unacceptable (maybe I'll draw
black instead).
This should fix all the threading cocoa bugs. Reopen if it's not the case!
Fixes #751
Fixes #1129
|
|
|
|
| |
Make it clear that this accesses the un-fullscreened window size.
|
| |
|
| |
|
|
|
|
| |
So that VO backends don't have to access the VO just for that.
|
|
|
|
|
|
|
| |
This should fix some crashes where we sent makeCurrentContext to a context that
was being freed from another thread.
/cc @mpv-player/stable
|
|
|
|
|
| |
I introduced this bug in b5bbb49. Sorry!
This could fix #943 and #930 even though I can't reproduce those specific bugs.
|
|
|
|
|
|
| |
This approach is similar to what other vo_opengl backends do. It can also be
used in the future to create another cocoa backend that renders offscreen
with IOSurfaces or FBOs.
|
|
|
|
|
|
| |
Not all the hardware supports kCGLPFASupportsAutomaticGraphicsSwitching
(apparently all Mid-2010 and before MacBooks do not work with it), so fallback
to not asking for this attribute in the GL pixel format.
|
|
|
|
| |
Fixes #820
|