Commit graph

28 commits

Author SHA1 Message Date
Julien Isorce
802bf79998 gl: add GstGLDisplayCocoa
https://bugzilla.gnome.org/show_bug.cgi?id=746012
2015-03-14 08:38:03 +00:00
Julien Isorce
74c294892d gl/cocoa: register only one custom nsapp loop
Otherwise the pipeline stalls when running
more than one glimagesink with gst-launch.

Also only register the custom nsapp loop
when setting up the nsapp from gstgl.
2015-03-02 07:49:26 +00:00
Julien Isorce
4801db552d gl/cocoa: instead of class_init use g_once to setup nsapp 2015-03-02 07:44:52 +00:00
Julien Isorce
8a0a71ff03 gl/cocoa: check for deprecated constants prior to OSX 10.10 2015-03-02 07:44:25 +00:00
Julien Isorce
4c4eec61e6 gl/cocoa: reduce custom main loop latency
This fix a very slow rendering rate regression that only
happens when using gst-launch, i.e. in the case where
the main thread does not run any NSApp loop.

Git bisect reported it has been introduced by the commit
e10d2417e2:
"move to CGL and CAOpenGLLayer for rendering".

Then the commit 7d46357627:
"gstglwindow_cocoa: fix slow render rate" attempted to fix
the slow rendering rate problem when using gst-launch.

At least for me it does not work. I tried several
combinations, for example to flush CA transactions in the
custom app loop, as mentioned in the doc, but the only solution
that fixes the slow rendering is by reducing the loop latency.
From what I tested, no need to put less than 60ms, even if the
framerate has an interval much lower (16.6ms for 60 fps).
2015-02-22 10:37:39 +00:00
Matthew Waters
0fd6872f7d gl/cocoa: don't deadlock if the dispatch_sync is called from the main thread
Provide a helper function to check whether we are being called from
the main thread and act appropriately.
2015-02-17 19:45:35 +11:00
Matthew Waters
ccf8b69a67 gl/cocoa: small refactor of layer/view creation into the window 2015-02-17 19:45:35 +11:00
Matthew Waters
4fc554054c glcontext/cocoa: avoid destroying a possibly 0 GSource id 2015-01-22 21:43:51 +11:00
Matthew Waters
e10d2417e2 gl/cocoa: move to CGL and CAOpenGLLayer for rendering
Removes the use of NSOpenGL* variety and functions.  Any Cocoa
specific functions that took/returned a NSOpenGL* object now
take/return the CGL equivalents.
2015-01-22 21:29:52 +11:00
Matthew Waters
fe8fdbdc7c glcontext/cocoa: add debug category 2015-01-22 21:27:44 +11:00
Sebastian Dröge
fa5c433e7e gl/cocoa: Disable hack for NSApp iteration with a special #define
The hack causes deadlocks and other interesting problems and it really
can only be fixed properly inside GLib. We will include a patch for
GLib in our builds for now that handles this, and hopefully at some
point GLib will also merge a proper solution.

A proper solution would first require to refactor the polling in
GMainContext to only provide a single fd, e.g. via epoll/kqueue
or a thread like the one added by our patch. Then this single
fd could be retrieved from the GMainContext and directly integrated
into a NSRunLoop.

https://bugzilla.gnome.org/show_bug.cgi?id=741450
https://bugzilla.gnome.org/show_bug.cgi?id=704374
2015-01-10 15:54:30 +01:00
Sebastian Dröge
1b2de14000 gl/cocoa: Don't init and clear static GMutex / GCond
We would potentially use it from the main loop later in
gst_gl_window_cocoa_init_nsapp() if it timed out before.
2015-01-08 09:36:24 +01:00
Sebastian Dröge
13c8517570 gl/cocoa: Remove GNUStep support
Until gcc and GNUStep properly support Objective-C blocks and other
"new" features of Objective-C we can't properly support them without
making the code much more ugly.

https://bugzilla.gnome.org/show_bug.cgi?id=739152
2014-11-13 12:01:19 +01:00
Matthew Waters
81ceca1aea glcontext: add api for retreiving the current context and api
that is current in the calling thread.
2014-10-28 17:33:20 +11:00
Sebastian Dröge
8d92b6a364 gl/cocoa: Improve the NSApplication initialization
This is only for non-Cocoa apps but previously caused a 2 second
waiting during startup for Cocoa apps. This is unacceptable.

Instead we now check a bit more extensive if something actually
runs on the GLib default main context, and if not don't even
bother waiting for something to happen from there.
2014-09-29 10:57:18 +03:00
Sebastian Dröge
66cb4166d3 gl/cocoa: Call UI related API from the application main thread 2014-09-29 10:57:18 +03:00
Sebastian Dröge
2173d34462 gl/cocoa: Switch to a plain NSView subclass instead of NSOpenGLView
We don't and can't use NSOpenGLView as it's supposed to be used and
it gets into our way by being to clever in various situations.
2014-09-29 10:57:18 +03:00
Sebastian Dröge
bc52e41641 gl/cocoa: Clear the current GL context when it should happen 2014-09-25 16:12:24 +03:00
Julien Isorce
6e51790a11 glcocoa: initalize NSApp asap when using gst-launch
See https://bugzilla.gnome.org/show_bug.cgi?id=732661
2014-07-03 10:39:44 +01:00
Julien Isorce
aa4bdcd707 gl/cocoa: set the view to use for drawing by the context
It avoids to draw to an invalid buffer.
Withtout this the default frame buffer is undefined:
glBindFramebuffer (GL_FRAMEBUFFER, 0)

Visually you could see some white frames at the beginning
when lunching videotestsrc ! glimagesink

With OpenGL Profiler from XCode you could see some
GL_INVALID_FRAMEBUFFER_OPERATION for the first frames
2014-04-24 09:09:13 +01:00
Julien Isorce
871ddef9ce gl/cocoa: fix NSAutoreleasePool initialization 2014-04-12 15:51:47 +01:00
Julien Isorce
3c49f0f42a gl/cocoa: ensure to call NSApplication:sharedApplication in the main thread
"(NSApplication *)sharedApplication This method also makes a connection
to the window server and completes other initialization"
The implicit thing which is not mentioned is that it required
to be called in the main thread.

Fix a regression introduces by 82b7c915bb
When using with gst-launch, it was not possible to click on the close
cross of the window anymore which is a bit anoying and also because
it's was possible before.

Prior to this commit the GstGLContextCocoaClass was initialized
in the main thread because gst_gl_context_new was called in the
state change function from going from ready to paused.

From this commit this call is done from the streaming thread.
So that the call to [NSApplication sharedApplication];
was not done in the main thread anymore.

We now ensure that by assuming there is a GMainLoop running.
It's for debugging purpose so that's ok to do that. Also
note we already do this assumtion to run app itereations.

The regression had no consequence on the cocoa/videooverlay example
(that should be moved from gst-plugins-gl to -bad) because the
application is responsible for that necessary call.
2014-04-12 15:46:47 +01:00
Edward Hervey
16e60d0129 gl/cocoa: Fix debug statements and platform 2014-03-17 14:06:53 +01:00
Matthew Waters
3ad466945e [891/906] context: add support for wrapping external contexts 2014-03-15 18:37:07 +01:00
Matthieu Bouron
fb9684e0f1 [836/906] cocoa: only use GSRegisterCurrentThread with GNUStep environment 2014-03-15 18:37:03 +01:00
Matthew Waters
db1c7a242b [818/906] window: add send_message_async vmethod
- provide a default synchronous send_message
- make context creation threadsafe again
2014-03-15 18:37:02 +01:00
Matthew Waters
b24021b1ac [801/906] context: Reimplement GL context sharing
https://bugzilla.gnome.org/show_bug.cgi?id=704806
2014-03-15 18:37:01 +01:00
Matthew Waters
95c08c2ee2 [794/906] context: add subclasses for the different platforms (egl, glx, wgl, etc)
- most code taken from the Window subclasses
- tested combinations: xEGL, GLX, Wayland+EGL, Cocoa (under GNUStep), WGL (Wine)
2014-03-15 18:37:01 +01:00