2012-03-04 21:04:07 +00:00
|
|
|
/*
|
|
|
|
* Cocoa OpenGL Backend
|
|
|
|
*
|
2013-09-03 19:18:28 +00:00
|
|
|
* This file is part of mpv.
|
2012-03-04 21:04:07 +00:00
|
|
|
*
|
2013-09-03 19:18:28 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or modify
|
2012-03-04 21:04:07 +00:00
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
2013-09-03 19:18:28 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2012-03-04 21:04:07 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
2013-09-03 19:18:28 +00:00
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
2012-03-04 21:04:07 +00:00
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
2013-09-03 19:18:28 +00:00
|
|
|
* with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2012-03-04 21:04:07 +00:00
|
|
|
*/
|
|
|
|
|
2011-10-15 16:44:00 +00:00
|
|
|
#ifndef MPLAYER_COCOA_COMMON_H
|
|
|
|
#define MPLAYER_COCOA_COMMON_H
|
|
|
|
|
cocoa: redo synchronization
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.
2015-05-13 20:00:34 +00:00
|
|
|
#include <stdbool.h>
|
|
|
|
#include <stdint.h>
|
|
|
|
#include <OpenGL/OpenGL.h>
|
2011-10-15 16:44:00 +00:00
|
|
|
|
cocoa: redo synchronization
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.
2015-05-13 20:00:34 +00:00
|
|
|
struct vo;
|
2012-09-13 07:32:59 +00:00
|
|
|
struct vo_cocoa_state;
|
|
|
|
|
2015-10-01 20:25:12 +00:00
|
|
|
void vo_cocoa_init(struct vo *vo);
|
2011-10-15 16:44:00 +00:00
|
|
|
void vo_cocoa_uninit(struct vo *vo);
|
|
|
|
|
2015-10-01 20:25:12 +00:00
|
|
|
int vo_cocoa_config_window(struct vo *vo);
|
2011-10-15 16:44:00 +00:00
|
|
|
|
2013-05-15 16:17:18 +00:00
|
|
|
int vo_cocoa_control(struct vo *vo, int *events, int request, void *arg);
|
2011-10-15 16:44:00 +00:00
|
|
|
|
cocoa: redo synchronization
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.
2015-05-13 20:00:34 +00:00
|
|
|
void vo_cocoa_swap_buffers(struct vo *vo);
|
|
|
|
void vo_cocoa_set_opengl_ctx(struct vo *vo, CGLContextObj ctx);
|
2012-05-14 14:33:06 +00:00
|
|
|
|
2011-10-15 16:44:00 +00:00
|
|
|
#endif /* MPLAYER_COCOA_COMMON_H */
|