Well, looks like I am wrong. I had assumed that wxWidgets managing these timer events and executing the callbacks whenever it could from within its message dispatch thread. I did a quick test, and indeed my key event is getting called while my timer callback is active. I guess the wxTimer is actually a wrapper over the Win32 asychronous timer API or something like that.
OK, I feel foolish...but yes, I did understand that unmanaged, concurrent acess to data is bad . Thanks for pointing this out. :) What's very strange is this was never a problem before, as I've made many scene changes this way in the 4-year history of my app. On Wed, Oct 8, 2008 at 3:54 PM, Chris <[EMAIL PROTECTED]> wrote: > I don't believe there is any concurrency going on. The "on timer" is in the > same thread as the key press. AFAIK it is the main app thread, i.e. the one > that receives window messages. I"m using wxWidgets' wxTimer class for the > timer. There is only one thread, and as I read the docs, it could only > work from the main thread anyway (see > http://docs.wxwidgets.org/stable/wx_wxtimer.html#wxtimer). > > In any event, I am reviewing the wxWidgets docs to see if there is a chance > the timer callback is in it's own thread, but the docs so far don't mention > that. > > > On Wed, Oct 8, 2008 at 3:32 PM, Tomlinson, Gordon < > [EMAIL PROTECTED]> wrote: > >> It seems from the information presented that your Basically running a >> multi-threaded GUI app like MFC/ WInd32 and trying to changing something >> that is being accessed concurrently ( which is bad) >> >> So as your key press happens in your application GUI event thread your on >> timer is also firing in its thread and drawing your text, this means your >> changing the text at the same time your trying to draw it >> >> its like getting your tires changed and trying to drive at the same time, >> your gonna come a cropper ;) >> >> You need to do your text changes in the void render() or in an update >> traversal callback, you need be able to pass data from your key press >> thread in a thread safe manner to your rendering thread to indicate a key >> was pressed and then act on that in void render() function >> >> >> >> >> *Gordon* >> >> __________________________________________________________ >> *Gordon Tomlinson* >> >> *Product Manager 3D >> **Email * : gtomlinson @ overwatch.textron.com >> __________________________________________________________ >> *(C): (+1) 571-265-2612 >> (W)**: (+1) 703-437-7651* >> >> "Self defence is not a function of learning tricks >> but is a function of how quickly and intensely one >> can arouse one's instinct for survival" >> - *Master Tambo Tetsura* >> >> >> >> ------------------------------ >> *From:* [EMAIL PROTECTED] [mailto: >> [EMAIL PROTECTED] *On Behalf Of *Chris >> *Sent:* Wednesday, October 08, 2008 3:22 PM >> >> *To:* OpenSceneGraph Users >> *Subject:* Re: [osg-users] osgText crash >> >> Sorry if I don't quite understand the GUI/render thread >> distinction...(learning as I go :) >> >> Pseudo code for adding/deleting is as follows, (all in the same (and only) >> thread,which receives GUI events) >> >> on_key_press() >> { >> toggle = ! toggle >> if (toggle) >> addTextToScene() >> else >> removeAndDeleteTextFromScene() >> } >> >> on_timer_event() // timer event occurs 30 times a second >> { >> renderScene() (calls the render function I quoted earlier) >> } >> >> On Wed, Oct 8, 2008 at 3:05 PM, Tomlinson, Gordon < >> [EMAIL PROTECTED]> wrote: >> >>> Were are you changing, adding, removing etc the text. >>> >>> You need to ensure you are updating only in the APP thread ( not a gui >>> thread ) >>> From the snippet below, you need to do this in the Render function ( or >>> that thread ) or in the Update traversal >>> >>> >>> *Gordon* >>> >>> __________________________________________________________ >>> *Gordon Tomlinson* >>> >>> *Product Manager 3D >>> **Email * : gtomlinson @ overwatch.textron.com >>> __________________________________________________________ >>> *(C): (+1) 571-265-2612 >>> (W)**: (+1) 703-437-7651* >>> >>> "Self defence is not a function of learning tricks >>> but is a function of how quickly and intensely one >>> can arouse one's instinct for survival" >>> - *Master Tambo Tetsura* >>> >>> >>> >>> ------------------------------ >>> *From:* [EMAIL PROTECTED] [mailto: >>> [EMAIL PROTECTED] *On Behalf Of *Chris >>> *Sent:* Wednesday, October 08, 2008 2:48 PM >>> *To:* OpenSceneGraph Users >>> *Subject:* Re: [osg-users] osgText crash >>> >>> Thanks Robert, >>> >>> I do realize it's tough to tell without seeing the code. Up to yesterday >>> I used osg 2.1, but just upgrade to 2.7.1 (bug still occurs). FWIW, I'm not >>> using the viewer setup in the examples, I use my own osgUtil::SceneView and >>> use cull & draw directly. Note I setup my viewport properties on each >>> rendered frame, as these are animated. The basic code is like: >>> >>> void render() >>> { >>> osgProducer::OsgSceneHandler *sh = >>> dynamic_cast<osgProducer::OsgSceneHandler *> ( _cam.getSceneHandler() ); >>> osgUtil::SceneView* sv = sh->getSceneView(); >>> sv->setSceneData( (osg::Node *) getSceneNode(0) ); >>> osg::State* state = sv->getState(); >>> state-> dirtyColorPointer(); >>> >>> sv->setProjectionMatrix( projection ); >>> sv->setViewMatrix( *_viewMatrix ); >>> sv->setViewport( clippedViewport.x, clippedViewport.y, >>> clippedViewport.xdim, clippedViewport.ydim ); >>> >>> //sv->update(); no anims, no need to update ? >>> sv->cull(); >>> sv->draw(); >>> } >>> >>> >>> On Wed, Oct 8, 2008 at 2:13 PM, Robert Osfield <[EMAIL PROTECTED] >>> > wrote: >>> >>>> Hi Chris, >>>> >>>> With so few details about your viewer setup and scene graph usage the >>>> best we can do is guess what you might have done wrong given other >>>> common mistakes we see pop up - have the DataVariance recommendation. >>>> >>>> Another thing you could try setting the threading model on the viewer >>>> by calling >>>> >>>> viewer.setThreadingMode(osgViewer::Viewer::SingleThreaded); >>>> >>>> Again it's a long shot given we really don't know enough about the OSG >>>> version you are using, which viewer library/classes and the fact >>>> you're trying to control everything thing through swig wrappers. >>>> >>>> Robert. >>>> >>>> On Wed, Oct 8, 2008 at 7:04 PM, Chris <[EMAIL PROTECTED]> wrote: >>>> > I had just read the osg archive and set the text DataVariance to >>>> DYNAMIC, >>>> > with high hopes..unfortunately still crashes :( >>>> > >>>> > _text->setDataVariance(osg::Object::DYNAMIC); >>>> > >>>> > I create my Text in response to a keystroke, and add it to the scene. >>>> The >>>> > next keystroke removes and deletes it. Each time I create it, the >>>> initial >>>> > rendered text string does not change. >>>> > >>>> > ( Also set my loaded osgText::Font to DYNAMIC DataVariance, doesn't >>>> help. ) >>>> > >>>> > BTW I noticed there were some nvidia problems in the archives; I do >>>> have an >>>> > NVidia driver (my machine is a Toshiba Tecra M4, Geforge Go 6200 >>>> (three >>>> > years old), driver date 3/14/2005, version 7.1.4.1 ) >>>> > >>>> > as per your StateSet DataVariance comment, should i do that as well ? >>>> I'm >>>> > not familiar with osg's thread models, but I just call render within >>>> my >>>> > app's main thread, and I dont' explicitly create other threads myself. >>>> > >>>> > On Wed, Oct 8, 2008 at 1:21 PM, Paul Melis <[EMAIL PROTECTED]> >>>> wrote: >>>> >> >>>> >> Robert Osfield wrote: >>>> >>> >>>> >>> Are you dynamically updating the text each frame? If so set the >>>> >>> DataVariance to DYNAMIC. >>>> >>> >>>> >> >>>> >> Hmmm, if setting it to STATIC causes a crash like this, might that be >>>> a >>>> >> design flaw? >>>> >> >>>> >> Paul >>>> >> >>>> >>> Robert. >>>> >>> >>>> >>> On Wed, Oct 8, 2008 at 6:09 PM, Chris <[EMAIL PROTECTED]> wrote: >>>> >>> >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> I'm having semi-random crash bugs when I add an osgText drawable to >>>> my >>>> >>>> scene. The actual error is a mem access violation, and it occurs >>>> after >>>> >>>> I've >>>> >>>> added & removed the node containing the drawable from the scene a >>>> random >>>> >>>> number of times' (usually from 1 to 10 times) >>>> >>>> >>>> >>>> The exception occurs in the same place in the call stack, >>>> apparently >>>> >>>> somewhere in my open gl .dll (nvoglnt.dll). One thing that puzzles >>>> me is >>>> >>>> that I'm using SWIG, and from the call stack the function >>>> >>>> PySwigObject_Check(PyObject *op) ) seems to call into the osgUtil >>>> .dll, >>>> >>>> which in about 10 stack layers ends up calling nvoglnt.dll. I don't >>>> know >>>> >>>> why >>>> >>>> 'PySwigObject_Check' would be caling the osg .dll, (see func copied >>>> >>>> below), >>>> >>>> but maybe some sort of wierd thread confusion ? >>>> >>>> >>>> >>>> SWIGRUNTIMEINLINE int >>>> >>>> PySwigObject_Check(PyObject *op) { >>>> >>>> return ((op)->ob_type == PySwigObject_type()) >>>> >>>> || (strcmp((op)->ob_type->tp_name,"PySwigObject") == 0); >>>> >>>> } >>>> >>>> >>>> >>>> The crash does NOT occur if I repeatedly create/delete the osgText >>>> >>>> drawable >>>> >>>> but don't add it to my scene. It does not crash during the render >>>> but >>>> >>>> seems >>>> >>>> to corrupt something that fails elsewhere (apparently in >>>> >>>> 'PySwigObject_Check' ) >>>> >>>> >>>> >>>> While I can't be certain it's not my code, I have been running the >>>> same >>>> >>>> render code (which uses osg) now for a few years without problems. >>>> Note >>>> >>>> that I dont explictly create extra threads in my code, beyond what >>>> osg >>>> >>>> might >>>> >>>> be doing. >>>> >>>> >>>> >>>> I thought this looked like some thread/mutex problem, or pehaps a >>>> VC++ >>>> >>>> STL >>>> >>>> problem (anyone had these issues with osg Text before?) I created >>>> a >>>> >>>> new >>>> >>>> version of osgText that hacks out the STL-based 'String' class used >>>> to >>>> >>>> 'setText', but no dice. >>>> >>>> >>>> >>>> I was running on WinXP, using compiler: Visual Studio .net 2002. I >>>> just >>>> >>>> installed Osg 2.7.1, and Visual Studio Express 9.0; but the crash >>>> still >>>> >>>> occurs. >>>> >>>> >>>> >>>> TIA, >>>> >>>> Chris >>>> >>>> >>>> >>>> -- >>>> >>>> www.sketch3.com >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> 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 >>>> >>> >>>> >> >>>> >> _______________________________________________ >>>> >> osg-users mailing list >>>> >> [email protected] >>>> >> >>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>>> > >>>> > >>>> > >>>> > -- >>>> > www.sketch3.com >>>> > >>>> > _______________________________________________ >>>> > 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 >>>> >>> >>> >>> >>> -- >>> www.sketch3.com >>> >>> _______________________________________________ >>> osg-users mailing list >>> [email protected] >>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >>> >>> >> >> >> -- >> www.sketch3.com >> >> _______________________________________________ >> osg-users mailing list >> [email protected] >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > > > -- > www.sketch3.com > -- www.sketch3.com
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
