We create our textures (in Desktop GL) with GL_TEXTURE_RECTANGLE,
vaapi attempts to bind our texture to GL_TEXTURE_2D which throws a
GL_INVALID_OPERATION error and as thus, no video.
Also, by moving exclusively to GL_TEXTURE_2D and the npot extension
we also remove a difference between the Desktop GL and GLES2 code.
https://bugzilla.gnome.org/show_bug.cgi?id=712287
- cmake could not find glib
- put gtk variables at the beginning to avoid GL conflicts
- update examples to clutter-1.8
- use const instead of deprecated G_CONST_RETURN
- set max pending events to 0 to make cube example works again
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.
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.
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.
