[GtkGLExt] Problem with thread pools and multiple drawables.

[Jose Commins <axora axora net>]

    Hi dudes, on the GTK forums there has been several requests for 
GStreamer example code, so I decided to go one further and do a more 
advanced version of my sample GTKGLApp that pipes GStreamer video via 
gtkglext drawables.

    However, as I am trying to do more advanced things with this 
example I have run into curious 'features' or what may be bugs in the 
underlying gl system.

    My current sample app has two GL-capable widget drawables that 
share a common display-list/context.

    I have the standard region-update callbacks that redraw each gl 
drawable by obtaining the gl-capable widget's context & drawable by 
'gtk_widget_get_gl_context' and 'gtk_widget_get_gl_drawable' before 
'gdk_gl_drawable_begin'.  At the start of the callback, I lock 
everything with a global render mutex and also with gdk_threads_enter - 
so there's no two callbacks/threads accessing the data at the same time.

    However, I have found a very, very strange thing:

    As it stands, the GStreamer 'new-buffer' callback gets the address 
of the pixel data, which for performance reasons I hand off elsewhere to 
upload to the GPU texture.

    If I do this upload within a timer (using g_timeout_add) that 
uploads the texture when data is available, everything is fine.  Nice 
smooth video :)

    If I do this upload with a thread (using a glib async queue to 
asynchronously wait for the new buffer and g_thread_create for the 
thread) then I will get "GdkGLExt-WARNING **: glXMakeCurrent() failed" 
and the widget fails to display.

    Both methods use *exactly the same code* and locking mechanisms to 
transfer the texture data.

    Also, if I try to up0load the texture within the GStreamer 
'new-buffer' callback, the same error.

    I am completely puzzled why a timer running in the same app works, 
and a thread running in the same app doesn't...  Am I seeing an obscure 
bug that involves thread/process pools and gtkglext?

Regards,
                Jose.