Re: [GtkGLExt] Problem with thread pools and multiple drawables.

[Jose Commins <axora axora net>]

    Hi, on follow up, I have some source code available so that you can 
see the quirk:
    
http://sourceforge.net/projects/gtkglapp/files/Release/GtkGLAppGStreamer.tar.gz/download
    In line 445 within 'thread_async_queue_push_handler'

    Change:

    thisGlContext = gtk_widget_get_gl_context (theDrawingArea1);

    To:

    glContext = theSharedGLContext;


    You will see the '"GdkGLExt-WARNING **: glXMakeCurrent() failed" 
error, despite all the other callbacks using 'theSharedGLContext', for 
some reason the async thread fails unless the context is extracted from 
the widget - and it's a different address!
    What's happening?

Regards,
            Jose.

On 02/12/2010 17:35, Jose Commins wrote:
>     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.