Hi Robert and All, I'm revamping this thread 'cause my question is related to it. Simon knows much more than I do about windows event handling, but I have tried to run the osgQtBrowser example under WinXP, and it works fine (with active navigation) both in threaded and single thread mode.
But on my side, I'd like to go the opposite way, which is having the control of the main thread and spawn a new one for the Qt browser. So far I've successfully isolated the Qt code in a component, not to "pollute" the main application code. This way it's easier to plug this component into any existing application. But with this single-threaded approach, the application hiccups when the page is loading (i.e. when the qtBrowser is retrieving network data), same as when osgQtBrowser run in single thread. Do you think it's possible to spawn this qt data loading in a separate thread, and then still connect to the "change" signal to update the image on the osg side? This new thread should also forward events to the WebView though, otherwise navigation is no more possible... I've checked the Qt documentation, but could not find a clean way to handle this case. Thank you, Ricky On Tue, Oct 20, 2009 at 1:11 PM, Simon Hammett <[email protected]>wrote: > 2009/10/20 J.P. Delport <[email protected]>: > > Hi Simon, > > > > Simon Hammett wrote: > >>> > >>> I will try osgqtbrowser on Windows and > >>> see what happens. > >>> > >>> Anyone else have reports on osgqtbrowser on Windows? > >>> > >>> thanks > >>> jp > >>> > >> Windozes is same as Mac, only the owner thread can retrieve events for > >> windows. > > > > can you expand on what you mean by "owner". If a thread other than main > > creates the viewer and that same thread calls frame(), will that work on > > Windows? > > > > jp > > Sort of. > > When a thread first creates a window, windows also creates the message > queue for the thread. > Windows messages are per thread, so only the thread which owns the > window will see the > messages for the window in it's event loop, so you can't have another > thread process mouse events, etc. > > The pure gl stuff does work though, so you can draw from another thread. > > With windows you should really make sure only one thread actually > creates windows as if you > have multiple windows in different threads the only safe > synchronisation primitive is MsgWaitForMultipleObjects which is a huge > pain in the butt. > > I've had a go at doing a properly separately threaded viewer window > before and even being extra careful I couldn't stop it dead locking. > > > > > -- > > This message is subject to the CSIR's copyright terms and conditions, > e-mail > > legal notice, and implemented Open Document Format (ODF) standard. The > full > > disclaimer details can be found at http://www.csir.co.za/disclaimer.html > . > > > > This message has been scanned for viruses and dangerous content by > > MailScanner, and is believed to be clean. MailScanner thanks Transtec > > Computers for their support. > > > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > -- > http://www.ssTk.co.uk > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Riccardo Corsi (t) +39 011 56 97 227 (f) +39 011 56 97 219 Virtual Reality & Multi Media Park SpA C.so Lombardia, 194 10149 Torino (It) C.F./P.I. 07844090014 C.S. deliberato € 2.220.240,80 - sottoscritto € 1.965.941,20 - versato € 819.253,90 Reg. Impr. TO-07844090014 R.E.A. 924212
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
