Default implementation of NSOpenglView::update is not safe because it
just calls update on the opengl context whereas we are not in the gl thread.
Also fix the white flickering when resizing, because now we need to call
the draw callback manually when resizing.
- All gstglwindow members are now modified only in the gl thread
to avoid thread concurrency
- OpenGL context is now properly clean
- fix a couple of things in implementation of xoverlay interface
It works with both gst-launch and a cocoa app (non-embedded and embedded)
But there is still some problems:
- sometimes crash when closing
- flickering when resizing
- embedded mode not perfect
I will first make the CMake build work with cocoa backend
in order to generate a XCode project.
Then it should be easier to fix those issues.
Greedyh operation implemented using OpenGL Shading Language.
We could add other operations later.
Does some good results but still not as expected.
That's why I do not add it yet to the build.
Fixes bug #584877
Before this commit calling "gst_x_overlay_set_xwindow_id" more
than one time, had no effect.
It mainly affects the glimagesink implementation.
But on win32 (and CE), some stuff has to be done to
release the old parent.
And add a switchxoverlay example where the user
can click on left/right part of the main window to
switch the xoverlay.
On linux, the GSource func attached to the clutter_threads_add_idle
was not getting the cpu ressource periodically.
Because the use of clutter_threads_enter/leave inside the fakesink
callback seems to be too strong.
So remove the use if clutter_threads_enter/leave in the fakesink callback.
Then replace GQueue by GAsyncQueue to keep thread safe access to the
communication queues between clutter and gst-gl.
Call clutter_threads_add_idle with high priority.
It requires at least clutter 0.8.6 since lower clutter versions are
not compatible with GL_TEXTURE_RECTANGLE_ARB.
Remove use of ClutterEffectTemplace since it does not exist in
clutter 0.9.
The external opengl context must be specify when creating
our OpenGL context (glx) or just after (wgl).
When calling glXCreateContext or wglShareLists, the
external opengl context must not be current.
Then our gl context can be current in the gl thread while
the external gl context is current in an other thread.
See tests/examples/clutter/cluttershare.c
Partially revert previous commit. It's not an issue with glimagesink
Xoverlay interface. It's always the same intel bug with direct
rendering redirection (the one that affects each opengl application
with compositing managers). It works fine with DRI2 and UXA
acceleration. Still leaving effects disabled because I'm testing intel
hardware that doesn't support FBOs.
