| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
init is a reserved keyword and Swift 4.2 got a bit stricter about using
it. this could be fixed by adding apostrophes around init but makes the
code uglier. hence i just renamed init to initialized and for
consistency uninit to uninitialized.
Fixes #5899
|
| |
|
|
|
|
|
|
|
|
|
| |
the pre-allocation was needed because the layer allocated a opengl
context async itself and we couldn't influence that. so we had to start
the core after the context was actually allocated. furthermore a window,
view and layer hierarchy had to be created so the layer would create
a context.
now, instead of relying on the layer to create a context we do this
manually and re-use that context later when the layer wants to create
one async itself.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
we rendered on the displaylink thread which wasn't the best idea. if
rendering took too long or was blocking it also blocked the displaylink
callback. when that happened new vsyncs were reported delayed or not at
all. consequently the mpv_render_context_report_swap function wasn't
called consistently and that could cause bad video playback. so the
rendering is moved to a dedicated dispatch queue. furthermore the update
callback starts a layer update directly instead of the displaylink
callback, making the rendering a bit more consistent.
|
| |
|
|
|
|
|
|
| |
commit 2edf00f changed the MPV_EVENT_SHUTDOWN behaviour slightly, such
that it will only be sent once. cocoa-cb relied on it being sent
continuously till all mpv_handles are destroyed. now it manually shuts
down and destroys the mpv_handle after the animation instead of relying
on this removed behaviour.
|
| |
|
|
|
|
| |
with the new libmpv API it's not necessary to check for this property
anymore since libmpv will only use the provided profile when it is
needed.
|
| |
|
|
|
|
|
| |
we activated the rendering loop a bit too early and it was possible that
the first draw function was called before it was actually ready. this
was a remnant from the old init routine and should have been changed.
start the queue on reconfigure instead of preinit.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
i tried being smart and handle aspect ratio differences manually via
atomic drawing and resizing to aspect fitted frames. there were a few
issues with that. like unexpected visibility of certain System GUI
elements on entering fullscreen or visually dropped frames due to the
atomic drawing. now we rely on system mechanics to keep the proper
aspect ratio of our layer, the recommended way. as a side effect it also
fixes a segfault.
Fixes #5581
|
| |
|
|
|
| |
a new replacement API was introduced with b037121 and the old one was
deprecated. porting cocoa-cb to the new API.
|
| |
|
|
|
|
|
|
|
|
|
| |
the title bar is now within the window bounds instead of outside. same
as QuickTime Player. it supports several standard styles, two dark and
two light ones. additionally we have properly rounded corners now and
the borderless window also has the proper window shadow.
Also make the earliest supported macOS version 10.10.
Fixes #4789, #3944
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
even though the fullscreen animation has a shorter duration than the
system wide animation (space sliding effect) there are still cases where
it takes longer, eg performance issues (especially on init). furthermore
the final size of the animation is usually different than the actual
fullscreen size because of spect ratio differences. the actual resize to
fullscreen is done automatically by cocoa itself when the actual
transition to fullscreen happens (system event). so it could happen that
the last animation resize happened after the actual resize to fullscreen
leading to a wrongly sized frame after entering fullscreen. to prevent
this we cancel the animation when entering fullscreen, we always set the
proper frame size when in fullscreen and discard any other frame sizes,
and to prevent some performance problems on init we push entering
fullscreen to the end of the main queue to execute it when most of the
init routines are done.
Fixes #5525
|
| |
|
|
|
|
|
|
|
| |
the CVDisplayLinkSetOutputHandler function introduced with 10.11 is
broken on the very same version of the OS, which caused our render loop
never to start. fallback to the old display link callback on 10.11.
for reference the radar http://www.openradar.me/26640780
Fixes #5527
|
|
|
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend in the future. the problems are various shortcomings of
Apple's opengl implementation and buggy behaviour in certain
circumstances that couldn't be properly worked around. there are also
certain regressions on newer macOS versions from 10.11 onwards.
- awful opengl performance with a none layer backed context
- huge amount of dropped frames with an early context flush
- flickering of system elements like the dock or volume indicator
- double buffering not properly working with a none layer backed context
- bad performance in fullscreen because of system optimisations
all the problems were caused by using a normal opengl context, that
seems somewhat abandoned by apple, and are fixed by using a layer backed
opengl context instead. problems that couldn't be fixed could be
properly worked around.
this has all features our old backend has sans the wid embedding,
the possibility to disable the automatic GPU switching and taking
screenshots of the window content. the first was deemed unnecessary by
me for now, since i just use the libmpv API that others can use anyway.
second is technically not possible atm because we have to pre-allocate
our opengl context at a time the config isn't read yet, so we can't get
the needed property. third one is a bit tricky because of deadlocking
and it needed to be in sync, hopefully i can work around that in the
future.
this also has at least one additional feature or eye-candy. a properly
working fullscreen animation with the native fs. also since this is a
direct port of the old backend of the parts that could be used, though
with adaptions and improvements, this looks a lot cleaner and easier to
understand.
some credit goes to @pigoz for the initial swift build support which
i could improve upon.
Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739,
#2392, #2217
|
