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.
GLimagesink XOverlay interface doesn't seem to work with composite
redirection on intel (and I believe ati too). Windows aren't
redirected offscreen at all. This commit just shows that the example
correcty works with ximagesink. The most evident difference I see is
that glimagesink reparents the xoverlay window into its own while both
x and xvimagesink destroy their window and render directly to the
xoverlay one.
Revert the "move windows" thing from commit
175f7a707bc922f3facc63e7d9b6d01f9bb6b1b0
Windows are offscreen who cares about their position? If you see the
windows something is going wrong with composite redirection.
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.
