Hi Carsten + Gerrit, Christoph Schäfer schrieb: > Hi Carsten > > Carsten Neumann schrieb: > >> Hello Christoph, >> >> attached version works for me on windows, but since it does not clean >> up properly after itself it may crash on exit. >> >> it becomes easier if you can set up threads/aspects in a >> producer-consumer style where the render thread only picks up changes >> but does not modify the scenegraph itself. >> From what you described, that would mean you'd have to transfer the >> input events to aspect 0 (perhaps setting up a queue, perhaps using >> some mechanism built into Qt, not sure what they have there) and >> handle them there. >> Then all changes to the scene would happen on aspect 0 and you'd just >> sync aspect 1 whenever an update is ready. >> >> Hope it helps, >> Carsten >> >> > Thanks for the updated example. Luckily I have already operations > functionality that can separating execution of ops from the issuing > thread. I'll try to switch to the suggested concept this weekend ;-) > > Cheers, > Christoph > First of all thank you very much for the great support provided here!
I finally nailed down the problem. It was not the sync, I switch all OpenSG operations exactly according to the order provided in Carsten's example and the problem persists. I then tried gDEbugger very hard. Finally I was able to get some results and compared them with debug results from the last example Carsten provided. It turned out I have 5GL contexts created during app startup. 4 get deleted and the last one would contain the model data. Strang enough it has shared display lists with context 3 which is deleted.... Okay now that I knew whats going wrong I had to remember back the days I started to test OpenSG2 with Qt4 and the real bad bad bad fast solution I used with a subclassed QGLWidget. What I need now is something like the OSGQ4GLWidget available in OpenSG 1.8 to separate render and interface thread and have the right contexts in place. Is that right? And if, well, is the porting of the QT4 parts on the short term roadmap? Cheers, Christoph ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
