I should have mentioned that :-) 3.0.1 on VC 2010 (64 and 32 bit) You can see the symptom with osgViewer launched with a large model ... if you step through the first time takeEvents() is called, there will be events with a time higher that the cut-off time - but only fractionally. Since the delta is so small it only takes a few frames before event processing starts. I think it has a lot to do with the order of object construction.
I our app the EventQueue seems to get constructed a lot earlier in the loading process. Since EventQueue's constructor sets _startTick to the time at construction, some events get added, and then setStartTick() is called again, that is what causes the problem. We have upgraded from 2.9 to 3.0.1 and also osgEarth 2.0 to 2.2. We certainly didn't see the problem with the older versions - maybe it is an issue that is only being exposed due to something in osgEarth 2.2. Anthony -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Osfield Sent: Wednesday, 20 June 2012 6:15 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Bug in osgGA::EventQueue? Hi Anthony, I don't have any answers from a first read through, and it's not a problem that's been reported as far as I can recall off the top of my head, so it'll probably require a code review of the relevant code and discussion to spot what might be amiss. Which version of the OSG are you using? Has the bug appeared when moving between OSG versions or changing your usage model of the OSG? Robert. On 20 June 2012 06:28, I-Nixon, Anthony D <[email protected]> wrote: > Hi Everyone: > > > > I'm seeing behavior in my application whereby an osg Window will come > up, but won't respond to any events for a few (sometimes 10 or more seconds). > Rendering is happening during this time, but no event processing. > > > > I tracked it down to the following: > > > > 1. The event queue is constructed and initializes _startTick > > 2. Some events are pushed onto the queue (not explicitly, could > be mouse move, etc) > > 3. Some time passes (generally related to model loading - we are > using > osgEarth) > > 4. Rendering starts and calls setStartTick() on the event queue > with a new time. > > 5. takeEvents() is called during event traversal, but because the > startTick has been reset, the top event is in the "future" and > takeEvents() returns nothing. > > 6. Eventually enough time passes so that the event is no longer > in the "future" and event processing starts happening. > > > > The time that the stall lasts for is clearly related to how long step > 3 takes - which can be lengthy when osgEarth is fetching stuff off the > network. > > > > I fixed it by clearing out the events when setStartTick is called, viz: > > > > > > void EventQueue::setStartTick(osg::Timer_t tick) > > { > > OpenThreads::ScopedLock<OpenThreads::Mutex> > lock(_eventQueueMutex); > > // Since setting the start tick effectively invalidates the time > > // of any events already in the queue, clear it out > > _eventQueue.clear(); > > _startTick = tick; > > } > > > > I haven't got a sample that reproduces the behavior, but it seems to > make sense that if the startTick is reset, all the existing events are toast? > I'm not sure why no one else has seen this - maybe our usage pattern > is different from the norm? > > > > Cheers > > > > Anthony > > > > Anthony Nixon > > Modelling & Simulation Architect > > Systems Analysis Laboratory (SAL) > > Strategic Development & Experimentation - International > > Boeing Defence Australia Ltd > > > > > > > _______________________________________________ > 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
