Re: [osg-users] GTK guru's please help!
On Thu, Nov 20, 2008 at 11:06 AM, Robert Osfield <[EMAIL PROTECTED]> wrote: > Now things are working with the new gecko plugin I'll check it in, and > others can test it out. The new plugin that wraps up the gecko based browser implementation is now checked into svn. The osgWidget::Browser API still very crude/experimental, as is the plugin, but it's a good first step towards make the embedded browser functionality available to all OSG apps. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GTK guru's please help!
Hi All, On Thu, Nov 20, 2008 at 9:53 AM, Robert Osfield <[EMAIL PROTECTED]> wrote: > Next I'm going to move all the GTK calls into osgWidget and see if a > conventional library rather than a plugin will be able to work > properly with gtk... This didn't work either. So I tried a different tack, I moved the init of the browser manager to the first time that a browser is requested rather than in the ReaderWriterUBrowser constructor. This little change fixed the problems with gtk initializing and the browser now comes up in the OSG window just fine. ;-) I can only imagine that UBrowser/GTK/LibXUL/xul-runner has some globals that automatically construct themselves and the order of their automatic construction was such that that my init code in my constructor introduced an order of initialization that wasn't safe. Lots of arm waving here... as very little actually changed code wise, it was just a timing change for the init... Now things are working with the new gecko plugin I'll check it in, and others can test it out. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GTK guru's please help!
HI All, On Thu, Nov 20, 2008 at 9:42 AM, Robert Osfield <[EMAIL PROTECTED]> wrote: > I will try out calling the gtk_init() from the main osgbrowser. This didn't work either, I still get the background thread hitting a pthread mutex deep inside gtk on my first call to gtk from the background thread. Next I'm going to move all the GTK calls into osgWidget and see if a conventional library rather than a plugin will be able to work properly with gtk... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GTK guru's please help!
Hi Jason and Jeremy, I've tried switching the order of the gtk_disable_setlocale(); and gtk_init(NULL, NULL); but it just hangs on gtk_init instead of gtk_disable_setlocale(). All my GTK calls and use of gecko is all done from a single back ground thread - this hasn't changed since moving the code from osgbrowser to the plugin. I will try out calling the gtk_init() from the main osgbrowser. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GTK guru's please help!
Jeremy Moles wrote: 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? Yeah, gtk_init() definitely needs to be the first GTK call you make. I've also run into problems with GTK managing resources in one thread and GLX resources being created or destroyed in another thread. I'm not sure that's what's happening here (I got crashes, not hangs), but it might be worth mentioning. The only other thing would be to make absolutely sure that all of the GTK calls are done from one thread. GTK *cannot* be multi-threaded under windows, and it requires some special handling under other OS's. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GTK guru's please help!
On Wed, 2008-11-19 at 20:51 +, 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 0x2b83392f1af8 in __lll_mutex_lock_wait () from /lib/libpthread.so.0
> #1 0x2b83392edaf5 in _L_mutex_lock_252 () from /lib/libpthread.so.0
> #2 0x2b83392ed4e7 in pthread_mutex_lock () from /lib/libpthread.so.0
> #3 0x2b8337a4f15b in ?? () from /lib64/ld-linux-x86-64.so.2
> #4 0x2b8337a52864 in ?? () from /lib64/ld-linux-x86-64.so.2
> #5 0x2b8337a58a52 in ?? () from /lib64/ld-linux-x86-64.so.2
> #6 0x2ab3e7c8 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"<
> gtk_disable_setlocale();
>
> osg::notify(osg::NOTICE)<<"UBrowserManager::getNativeWindowHandle()
> AA"<
> 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"<
> 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"<
> gtk_widget_realize(rtnw);
> GTK_WIDGET_UNSET_FLAGS(GTK_WIDGET(rtnw), GTK_NO_WINDOW);
>
> osg::notify(osg::NOTICE)<<"UBrowserManager::getNativeWindowHandle()
> D"<
> _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
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] GTK guru's please help!
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 0x2b83392f1af8 in __lll_mutex_lock_wait () from /lib/libpthread.so.0
#1 0x2b83392edaf5 in _L_mutex_lock_252 () from /lib/libpthread.so.0
#2 0x2b83392ed4e7 in pthread_mutex_lock () from /lib/libpthread.so.0
#3 0x2b8337a4f15b in ?? () from /lib64/ld-linux-x86-64.so.2
#4 0x2b8337a52864 in ?? () from /lib64/ld-linux-x86-64.so.2
#5 0x2b8337a58a52 in ?? () from /lib64/ld-linux-x86-64.so.2
#6 0x2ab3e7c8 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"
