Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fullscreen performance regression on OS X El Capitan #2392

Closed
franzf opened this issue Oct 11, 2015 · 66 comments
Closed

Fullscreen performance regression on OS X El Capitan #2392

franzf opened this issue Oct 11, 2015 · 66 comments
Labels

Comments

@franzf
Copy link

franzf commented Oct 11, 2015

This is a regression I've noticed since upgrading from Yosemite. Drawing the OSD and progress bar are way too CPU intensive, to the point where mpv will skip frames. To illustrate it, I've recorded the screen of my old, weaker laptop:

screen

While just playing a panning scene normally skips 2 frames, moving the mouse to trigger the OSD makes the CPU usage shoot up, where even mpv notices, skipping 98 frames. That's a worst case scenario on a Core 2 Duo, but the CPU usage is noticeable even on my newer machines.

mpv git-78caf6a, ffmpeg 2.8, OS X 10.11 15A284

@NiLuJe
Copy link

NiLuJe commented Oct 11, 2015

OpenGL performance seems to have taken a hit (at least some aspects of it), I've also had to tone down my config since moving to 10.11 (that's on a relatively recent MB Air).

I haven't noticed anything on the OSD end, but then I don't rely on it very much. On the contrary, CPU usage seems to be down a tiny bit, but unless I tone down my opengl settings (killing deband, for instance), I get skipped frames where I never did before.

@AirPort
Copy link

AirPort commented Oct 11, 2015

Regarding OpenGL general performances, yesterday in IRC we discovered that for some reason the --fs-black-out-screens option improve them drastically in fullscreen on 10.11, you can try it and see if it's useful in your case too.

@ghost
Copy link

ghost commented Oct 11, 2015

Yes, pigoz was talking about something like a window server performance regression.

@ChrisK2 ChrisK2 added the os:mac label Oct 11, 2015
@pigoz
Copy link
Member

pigoz commented Oct 11, 2015

Anyway I don't think its our bug :/

@NiLuJe
Copy link

NiLuJe commented Oct 11, 2015

At a (very) quick glance, fs-black-out-screens doesn't seem to help on my end (I'm not using any external screens, FWIW), the only thing it does is spawn an extra black mpv window that I can see in Mission Control. Speaking of Mission Control, strangely enough, the mpv thumbnail is completely smooth in there, during stuff that will skip like hell if I focus the window or go fullscreen. :?

@haasnhoff
Copy link

I've noticed the full-screen performance issue after upgrading to El Capitan, very annoying. It appears often if file operations are performed like copying a bigger file or using a VM in the background. My laptop has issues with it frequently. Reverting the config does obviously not fix it. Happens on both my desktop, and my laptop, so it's clearly not a device issue.

Unfocusing the mpv window does speed it up considerably when in full-screen. It's like the issue only happens if the window is in focus. Setting --quiet on helps, but doesn't fix it. Might as well also mention that I tried a very old build of mpv and it seemed to fix it too, but I can't confirm that 100%.

Seems like the --fs-black-out-screens option does fix the full-screen issue, though that is also annoying since I have three monitors connected and often have something I'm working on in one of the other monitors, but I guess that's a good temporary fix, especially on the laptop. I assume this is something on Apple's end since it isn't fixed yet, though only mpv has this problem as far as I know(?).

The full-screen thing might not related to the issue you are having however. Haven't noticed any noticeable skips on either of the rigs with the OSD, though when you do mention it I changed the msg-level to check and the dropped frames are indeed increasing whenever the OSD is showing.

@greentop
Copy link

Not sure if related, but recently on Ubuntu 14.04 64bit, I've been seeing the player shoot up to a consistent full CPU usage whenever I use vo=opengl-hq or vo=opengl in the config. Before, the player would rarely breach half the cpu usage in vo=opengl-hq on most 720p h264 video on the AMD Athlon II X4 640. If I switch to vo=vdpau (no hwdec=vdpau option), the CPU usage sees not much more than around 8%.

mpv-build:
From https:/FFmpeg/FFmpeg
2a4d1a6..624057d master -> origin/master
eca7b0d..c149a4a release/2.8 -> origin/release/2.8

From https:/mpv-player/mpv
78caf6a..bddd1e9 master -> origin/master

Playback test vo=opengl:
Playing: /home/green/Videos/Video Shared/screen tearing test.mp4
(+) Video --vid=1 () (h264)
(+) Audio --aid=1 --alang=und (
) (aac)
libEGL warning: DRI2: failed to authenticate
[vo/opengl] Suspected software renderer or indirect context.
AO: [pulse] 44100Hz stereo 2ch float
VO: [opengl] 1280x720 yuv420p
AV: 00:00:12 / 00:00:30 (41%) A-V: 0.000 Dropped: 126

Playback test vo=vdpau:
Playing: /home/green/Videos/Video Shared/screen tearing test.mp4
(+) Video --vid=1 () (h264)
(+) Audio --aid=1 --alang=und (
) (aac)
AO: [pulse] 44100Hz stereo 2ch float
VO: [vdpau] 1280x720 yuv420p
[vo/vdpau] Compositing window manager detected. Assuming timing info is inaccurate.
(Paused) AV: 00:00:07 / 00:00:30 (23%) A-V: 0.000

@ghost
Copy link

ghost commented Oct 12, 2015

There are several factors here:

  • El Crapitan has some sort of performance regression that affects us, and which --fs-black-out-screens appears to work around
  • vo_opengl_hq has become much slower due to the addition of debanding (enabled by default)
  • vo_opengl may have become somewhat slower due to the removal of the single-pass optimization, which can be restored with --vo=opengl:dumb-mode=yes (but which also disables almost all other filtering)

The VO changes were both included in release 0.11.0 for the first time.

@pigoz
Copy link
Member

pigoz commented Oct 12, 2015

The performance regression seems to only affect full screen mode though.

@NiLuJe
Copy link

NiLuJe commented Oct 12, 2015

FWIW, --fs-black-out-screens doesn't seem to help on my end (MB Air, no external screens).

Stupid question: What about resurrecting native-fs?

@pigoz
Copy link
Member

pigoz commented Oct 12, 2015

We could look into resurrecting --native-fs and see if it helps with performance.

@greentop
Copy link

The vo=opengl:dumb-mode=yes brings the total cpu usage down to 54%, which is still way too high. That number (54%) is about where vo=opengl-hq when debanding was enabled by default last month would take my cpu up to (~50% cpu usage then).

@marlencrabapple
Copy link

Am I right to think --fs-black-out-screens won't help those of us without external monitors? I should probably mention other video players (namely VLC) aren't affected by the El Capitan performance regression. I'm assuming this is because VLC uses OS X's native full screen API. Is implementing this in mpv a reasonable solution?

Edit: --native-fs is probably what I'm thinking of. First time I saw it I just assumed 'fs' stood for file system. Time to adjust my caffeine intake I guess.

@pigoz
Copy link
Member

pigoz commented Oct 16, 2015

We might look into implementing something like that. --fs-black-out-screens apparently helps regardless of the number of screens.

@FrostedMint
Copy link

Here’s what I’ve observed, mpv-0.11, 10.11.1, 1.1 GHz 12” MacBook (so, very slow hardware). Default full screen is slow. Full screen with --fs-black-out-screens works fine. If I hit the zoom button on the titlebar (i.e. native full screen) it’s fine.

My video output is set as vo=opengl:icc-profile-auto:blend-subtitles:interpolation:scale=spline36:cscale=spline36:dscale=mitchell:pbo

My full config.

@NiLuJe
Copy link

NiLuJe commented Oct 23, 2015

Sadly, --fs-black-out-screens still doesn't help on my end ;'(.

@sumyungguy
Copy link

In case it's not clear from FrostedMint's comment, despite --native-fs having been removed some time ago, you can already get native fullscreen in 10.11 without it being resurrected, by clicking the green button on the titlebar.

@chyiz
Copy link

chyiz commented Dec 12, 2015

On my end, both --fs-black-out-screens and native fullscreen doesn't help.
This minimal vo is enough to cause framedrop: vo=opengl:scale=spline36:interpolation

@chyiz
Copy link

chyiz commented Jan 11, 2016

I made some more test.
I set my vo back to a demanding one: opengl-hq:scale=ewa_lanczossharp:icc-profile-auto:interpolation, and also set framedrop=decoder. The video was choppy at first but after about 5 seconds it started to play smoothly. I can see the avsync dropped to 0 and there were no more frame drop.

I then tried framedrop=no, the video was a bit slow at first, but after few seconds it suddenly speed up for a second and then started to play smoothly. The avsync also dropped to 0 at the same time.

@ghost
Copy link

ghost commented Jan 11, 2016

framedrop=decoder might just not work, but the default framedrop mode should not cause any issues.

@franzf
Copy link
Author

franzf commented Jan 11, 2016

I don't know if it's just an impression, but I think today's 10.11.4 beta (15E27e) improved the performance a lot. I'm not getting any frameskips on mouse movement with the same file as the original post at all. Can someone confirm I'm not going crazy? Would be way too convenient for Apple to fix everything at once in this release lol

@pigoz
Copy link
Member

pigoz commented Jan 11, 2016

Would not be surprising because x.4 is generally the good release when stuff gets fixed.

@chyiz
Copy link

chyiz commented Jan 13, 2016

I'm on 10.11.4 beta now but I didn't notice any difference. I'm glad that your problem is fixed.
I made some more test and I feel like I'm the one going crazy.
I'm using this osd suggested by @FrostedMint to monitor my frame drop:

osd-msg2='VO: ${vo-drop-frame-count}\nDecoder: ${drop-frame-count}\nAV/Sync: ${avsync}'

Here is what I noticed:

On default framedrop=vo, framedrop starts as soon as I enter fullscreen. I can see avsync jumping back and forth, from around 0.005 to around 0.2xx and never settle down. vo frame drop count keep rising.
I then use a keyboard shortcut to switch framedrop mode to framedrop=decoder, decoder frame drop count increases to about 100, but in the mean time avsync quickly drop to zero. After that, video plays smoothly. Now even if I cycle framedrop back to framedrop=vo, exit full screen and come back, I still won't experience any frame drop.
However if I leave it at framedrop=vo, and make a seek action, like seek forward 5 seconds, all the frame drops come back.

The last interesting part is, when I'm trying to record my screen with Quicktime to show you guys how it behaves, the framedrop doesn't happen when the recording is on...

Here are my logs:
mpv-log.txt
mpv-stats.txt

@FrostedMint
Copy link

The frame drops have mysteriously stopped for me. A few days ago I did a brew upgrade, and rebuilt libass without harfbuzz (for #2585). I tried rebuilding libass with harfbuzz, but I can't get the frame drops to come back. So, maybe try a brew upgrade?

@Akemi
Copy link
Member

Akemi commented Mar 13, 2017

if you have time to test it there it would be appreciated. though funny, i have a mid 2010 MBP too, the one with a GT330M/Intel HD combination, and i never had the fullscreen problems there.

@AirPort
Copy link

AirPort commented Mar 13, 2017

Well, apparently I can't reproduce the regression anymore in the 2010 MBP with updated Sierra, not even with old 0.20.0 (prior to the fix). I'm sure that at least with El Capitan I needed --fs-black-out-screens (see #2392 (comment)), but I stopped using this mac almost a year ago and updated it only recently after reparing the faulty GPU, so I'm not sure what exactly changed in the meantime.
But in the end it seems that I can't be useful in testing this, sorry.

@Akemi
Copy link
Member

Akemi commented Apr 30, 2017

PR #4391 changes quite a few things back like they are supposed to be. @Cpuroast confirmed that the issue here is still fixed with it, though i hope for some more input. so if possible pls try the PR if possible and report back here, additional issues you encounter should be reported on the PR.

@Akemi Akemi mentioned this issue Sep 17, 2017
Akemi added a commit to Akemi/mpv that referenced this issue Dec 11, 2017
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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
an 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: mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Dec 11, 2017
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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
an 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: mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Dec 28, 2017
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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
an 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: mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Dec 28, 2017
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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
an 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: mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Dec 28, 2017
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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
an 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: mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Jan 14, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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
an 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:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Jan 14, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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
an 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:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Jan 20, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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
an 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:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Jan 20, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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
an 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:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Jan 30, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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
an 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:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Jan 30, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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
an 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:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217

cocoa-cb: initial implementation via opengl-cb API
Akemi added a commit to Akemi/mpv that referenced this issue Jan 31, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Jan 31, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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:
mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739, mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Feb 3, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739,
mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Feb 7, 2018
this is meant to replace the old and not properly working vo_gpu/opengl
cocoa backend. the problems are various shortcomings of Apple's opengl
implementation and buggy behaviour in certain circumstances that can'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

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: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739,
mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Feb 12, 2018
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: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739,
mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Feb 12, 2018
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: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739,
mpv-player#2392, mpv-player#2217
Akemi added a commit to Akemi/mpv that referenced this issue Feb 12, 2018
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: mpv-player#5478, mpv-player#5393, mpv-player#5152, mpv-player#5151, mpv-player#4615, mpv-player#4476, mpv-player#3978, mpv-player#3746, mpv-player#3739,
mpv-player#2392, mpv-player#2217
kevmitch pushed a commit that referenced this issue Feb 12, 2018
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
@Akemi
Copy link
Member

Akemi commented Feb 12, 2018

fixed via c5e4538.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.