On Wed, 2008-11-19 at 20:51 +0000, Robert Osfield wrote:
> Hi Guys,
>
> I'm now wrapping my first pass at browser support in the OSG by moving
> the LLMozLib/LibXUL implementation in the osgbrowser example off into
> a plugin. The work moving the code was pretty straight forward as
> I've always had this change in mind, but now I've moved on to
> debugging the code... which is where some GTK assistance would be of
> great help.
>
> GTK is required under Linux when using libXUL/xul-runner as gecko is
> based on GTK under Linux, and even though we are using a embedded
> browser for renderer where GTK doesn't have an influence, libXUL still
> needs to be passed a GTK widget and the workaround using in
> UBrowser/LLMozLib was to create a widget pass this to libXUL and then
> never use if for actual application windowing. This is pretty hacky
> but does work, or at least it did work when the code was in the
> osgbrowser application. Exactly the same code, executed in exactly
> the same sequence is hanging on the first call to gtk. The line of
> code that my app is hanging at is:
>
> gtk_disable_setlocale();
>
> This is the first call to GTK in the whole app, there aren't even any
> X11 calls made before this either - just in exactly the same way as
> done before when inside osgbrowser. The only difference is that the
> plugin that contains this GTK init code is dynamically loaded at
> runtime.
>
> So... does this ring any bells for GTK users? Is there some caveat
> that GTK can't be dynamically loaded as a plugin?
>
> The stack trace at the hang shows GTK stuck in a mutex lock. The
> UBrowserManager::getNativeWindowHandle () code at the bottom of the
> below trace is my method that calls gtk_disable_setlocale();
>
> #0 0x00002b83392f1af8 in __lll_mutex_lock_wait () from /lib/libpthread.so.0
> #1 0x00002b83392edaf5 in _L_mutex_lock_252 () from /lib/libpthread.so.0
> #2 0x00002b83392ed4e7 in pthread_mutex_lock () from /lib/libpthread.so.0
> #3 0x00002b8337a4f15b in ?? () from /lib64/ld-linux-x86-64.so.2
> #4 0x00002b8337a52864 in ?? () from /lib64/ld-linux-x86-64.so.2
> #5 0x00002b8337a58a52 in ?? () from /lib64/ld-linux-x86-64.so.2
> #6 0x00002aaaaab3e7c8 in UBrowserManager::getNativeWindowHandle ()
> from /home/robert/OpenSceneGraph/lib/osgPlugins-2.7.6/osgdb_gecko.so
>
> The complete function where the hang occurs is provide below,
> including my notify statements that isolate how far the thread gets,
> the second notify statement - the AA is never executed.
>
> void* UBrowserManager::getNativeWindowHandle()
> {
> if (_nativeWindowHandle) return _nativeWindowHandle;
>
> osg::notify(osg::NOTICE)<<"UBrowserManager::getNativeWindowHandle()
> A"<<std::endl;
>
> gtk_disable_setlocale();
>
> osg::notify(osg::NOTICE)<<"UBrowserManager::getNativeWindowHandle()
> AA"<<std::endl;
>
> gtk_init(NULL, NULL);
I've always been under the impression that gtk_init() has to be called
first before any fuction that begins with gtk_*, have you tried moving
it as the first call instead of disable_setlocale?
What if you call gtk_init() in the "main" code before doing anything
that forces the loading of the plugin?
> osg::notify(osg::NOTICE)<<"UBrowserManager::getNativeWindowHandle()
> B"<<std::endl;
>
> GtkWidget *win = gtk_window_new(GTK_WINDOW_POPUP);
> // Why a layout widget? A MozContainer would be ideal, but
> // it involves exposing Mozilla headers to mozlib-using apps.
> // A layout widget with a GtkWindow parent has the desired
> // properties of being plain GTK, having a window, and being
> // derived from a GtkContainer.
> GtkWidget *rtnw = gtk_layout_new(NULL, NULL);
> gtk_container_add(GTK_CONTAINER(win), rtnw);
>
> osg::notify(osg::NOTICE)<<"UBrowserManager::getNativeWindowHandle()
> C"<<std::endl;
>
> gtk_widget_realize(rtnw);
> GTK_WIDGET_UNSET_FLAGS(GTK_WIDGET(rtnw), GTK_NO_WINDOW);
>
> osg::notify(osg::NOTICE)<<"UBrowserManager::getNativeWindowHandle()
> D"<<std::endl;
>
> _nativeWindowHandle = rtnw;
>
> return _nativeWindowHandle;
> }
>
> Only other clues I can provide is that I'm calling GTK from a
> background thread that the plugin starts for the purpose of doing the
> browser rendering. All GTK calls are made from this single thread.
> This code threaded approach worked perfectly when the code was inside
> osgbrowser, the code itself identical - I just copied it into the
> plugin.
>
> I'm stumped.... so would love some greater wisdom as my GTK experience
> goes about as far as this little osgbrowser folly :-)
>
> Robert.
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
