Hi Anthony, Thanks for the information. Could you try the svn/trunk version of the OSG? This week I checked in refactor of the Viewer::advance()/eventTraversals() methods so that the call to EventQueue::frame() is done after the events are collected from the graphics windows. This refactor was done to address an issue with the mouse position and button mask not being passed onto to the frame event right away (it was delayed by a frame in 3.0.x). This change will also affect the event timing a little, I can't say whether it'll effect the issue you are seeing yet as I haven't yet reproduced it, but it would sure be worth checking.
Robert. On 21 June 2012 07:40, I-Nixon, Anthony D <[email protected]> wrote: > 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 _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
