- 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.
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.
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
In OpenGL 2.x for Embedded System, a lot of basic scene/draw functions
have been removed. It means that everything is made using vertex and
fragment shaders.
I have also added a gstglwindow backend for winCE that uses EGL
(Native Platform Graphics Intercace) (which is a full part of
OpenGL ES specification). It remove the use of wgl/glx functions.
Althought the XEvent's xclient.data.l array is an array of
longs they will be constrained to 32 bit by the X11 protocol.
On 64 bit architectures use two elements of the array to store
one pointer.
This fixes segfaults that happen at least for every example
on startup.
This reverts commit 96e4ab18c2cf9876f6c031b9aba6282d0bd45a93.
You should have asked first. And you would have been told "no",
because it causes people on development branches to do a huge
amount of extra work.
Althought the XEvent's xclient.data.l array is an array of
longs they will be constrained to 32 bit by the X11 protocol.
On 64 bit architectures use two elements of the array to store
one pointer.
This fixes segfaults that happen at least for every example
on startup.
