Re: [osg-users] Bug in osgGA::EventQueue?

[I-Nixon, Anthony D]

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: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] 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  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 
> 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
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
> org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Bug in osgGA::EventQueue?

[I-Nixon, Anthony D]

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 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
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgDB::Registry bug with files not loading after an archive has been accessed

[I-Nixon, Anthony D]

Hi Guys:

I've found a problem when upgrading our application to 3.0.1 (from 2.8) whereby 
files (fonts, models, etc) fail to load *after* an archive has been loaded.  If 
no archive has been loaded, everything is fine.

The offending code appears to be this in Registry::read() added at rev 12638:

// check loaded archives.
AvailableArchiveIterator aaitr(_archiveCache, _archiveCacheMutex);
for(;aaitr.valid();++aaitr)
{
ReaderWriter::ReadResult rr = readFunctor.doRead(*aaitr);
if (readFunctor.isValid(rr)) return rr;
else results.push_back(rr);
}

If an archive has been loaded, this code causes FILE_NOT_FOUND to be pushed 
onto the results vector if the file being loaded is not part of the archive.  
This causes the function to exit later before any other (currently not loaded) 
plugins get a chance at loading the file.

Making the following change fixes the issue for me, but it may be a bit naive?

// check loaded archives.
AvailableArchiveIterator aaitr(_archiveCache, _archiveCacheMutex);
for(;aaitr.valid();++aaitr)
{
ReaderWriter::ReadResult rr = readFunctor.doRead(*aaitr);
if (readFunctor.isValid(rr)) return rr;
else if (rr.status() != ReaderWriter::ReadResult::FILE_NOT_FOUND) 
results.push_back(rr);
}

A small test program reproduces the problem:

int main(int arg, char* argv[])
{
 osg::Node* pNode1 = osgDB::readNodeFile("a path to a .osga");
 osg::Node* pNode2 = osgDB::readNodeFile("a path to a .flt");// Needs to be 
a file type that is not contained in the archive
 return 0;
}

Given the above, pNode2 will be null ... reverse the order of the two lines and 
pNode1 and pNode2 will be valid.

Cheers

Anthony

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgViewer::CompositeViewer Texture Issue

[I-Nixon, Anthony D]

I have seen a similar problem to this,  but only with paged terrain
databases.  My problem was that the second view would not load textures
that had already been loaded by the first view.
 
Calling
view->getDatabasePager()->setUnrefImagedataAfterApplyPolicy(true,
false);
 
fixed it for me, but I've never been sure if that was the "correct" way
of fixing the problem.  I'm not sharing contexts between the views
(perhaps I should be).
 
I'm currently running 2.9.3 but have seen this of 2.8.1 as well - on
nVidia with the latest drivers.
 
Anthony Nixon




From: Mark Sciabica [mailto:msciab...@itracs.com] 
Sent: Wednesday, 15 July 2009 12:41 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] osgViewer::CompositeViewer Texture
Issue



Hello Roger,

I remember running into a similar problem that I attributed to
an nVidia driver bug. You might want to try upgrading your driver. I
worked around the problem by calling dirtyTextureObject() on each
texture in the model whenever I created a new window, forcing the driver
to reload the texture data from system memory. I think the driver got
confused with shared contexts and this function was an effective
reminder of what the texture data was supposed to be.

Regards,



Mark

 

-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Printy,
Roger-P57305
Sent: Tuesday, July 14, 2009 8:36 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] osgViewer::CompositeViewer Texture Issue

 

I am upgrading to OSG 2.8.1 from OSG 2.4 and am having a problem
with use of the osgViewer::CompositeViewer.  My application
adds/destroys views dynamically and I am having an issue when I have two
views loaded with the same terrain/textures (for example a terrain) when
I close one view the textures in the 2nd view all get removed from the
scene.  The only way I am able to get the textures in the remaining view
to reload is to close the view, leaving none open, and opening a new
view.  This process destroys and recreates the composite viewer.

I have tried calling setUnrefImagedataAfterApplyPolicy(true,
false) on each view as they are created but this has not helped resolve
the issue.

Can anyone provide any advice to help with this? 

Thanks, 
Roger 

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Multithreadingcrash due toosgDb::Registry::instance()

[I-Nixon, Anthony D]

Thanks for the pointer Paul.  The points you raise do apply to C++ as
well, and it seems the consensus is that it is not possible to implement
the double-checked locking pattern in portable C++ safely.

See Scott Meyer's and Andrei Alexandrescu's paper here
http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf  

If Scott Meyer's says it can't be done, I tend to believe him :-)

>From Scott's paper:

"In many cases, initializing a singleton resource during single-threaded
program startup
(e.g., prior to executing main) is the simplest way to offer fast,
thread-safe
singleton access."

So the best thing to do is to advertise in large bold letters somewhere
in the doco (and FAQ) that if you are going to use multithreading, all
instances need to be accessed before threading starts.

Anthony

> -Original Message-
> From: Paul Speed [mailto:psp...@progeeks.com] 
> Sent: Friday, 20 March 2009 2:21 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Multithreadingcrash due 
> toosgDb::Registry::instance()
> 
> Just a note for those of us who have been bitten by double 
> check locking issues in Java, this technique is highly 
> dependent on the threading and data architecture in use.  
> There are subtle issues between when a thread commits its 
> local state and the possibility for the compiler to reorder 
> statements.  This was less of an issue on single-core boxes 
> but comes up in multi-core where the local thread state may 
> not be committed.  I can't be sure but there may have also 
> been some subtle statement reordering issues with respect to 
> the compiler not knowing that your guard release _must_ be 
> run after the instance_ = new Singleton has _fully_ executed.
> 
> I don't know if these problems crop up in C++ but it 
> certainly seems like they could depending on the threading 
> implementation and compiler optimization strategy.
> 
> Worst case for a singleton pattern is that you might get a 
> race condition where two instances are created.  There are 
> other double-checked locking situations that are much more insidious.
> 
> -Paul
> 
> Paul Melis wrote:
> > Robert Osfield wrote:
> >> 2009/3/17 Schmidt, Richard  >> >
> >>
> >> http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf
> >> 
> >>
> >>
> >> Could you explain what the above document is all about...
> > I just read it an it describes a pattern where you use a mutex to 
> > guard access to the singleton's _instance value, but in such a way 
> > that the mutex is only needed when _instance == NULL, i.e.
> > 
> > class Singleton
> > {
> > public:
> >static Singleton *instance (void)
> >{
> > // First check
> > if (instance_ == 0)
> >{
> >   // Ensure serialization (guard constructor 
> acquires lock_).
> >  Guard guard (lock_);
> >  // Double check.
> >  if (instance_ == 0)
> >   instance_ = new Singleton;
> >}
> > return instance_;
> > // guard destructor releases lock_.
> >}
> > private:
> >static Mutex lock_;
> >static Singleton *instance_;
> > };
> > 
> > This should give you thread-safe access to Singleton->instance() at 
> > all times combined with correct initialization.
> > 
> > Quite neat actually,
> > Paul
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
> > org
> 
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
negraph.org
> 
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Multithreading crashduetoosgDb::Registry::instance()

[I-Nixon, Anthony D]

I'll have a crack at it, unless someone else is already doing it.  I've got an 
environment here that exercises the issue consistently.
 
Anthony




From: Robert Osfield [mailto:robert.osfi...@gmail.com] 
Sent: Tuesday, 17 March 2009 8:22 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Multithreading 
crashduetoosgDb::Registry::instance()


HI Richard + Paul,

Thanks for explanation.  Feel free to dive in an code up such a 
solution.

Robert.


On Tue, Mar 17, 2009 at 10:17 AM, Schmidt, Richard 
 wrote:


The document is about a design pattern called double locking, 
which is especially suitable for singleton objects in multithreaded 
environments.

The pattern is essentially this:


static Singleton *instance (void)
{
// First check
if (instance_ == 0)
{
// Ensure serialization (guard
// constructor acquires lock_).
Guard guard (lock_);
// Double check.
if (instance_ == 0)
instance_ = new Singleton;
}
return instance_;
// guard destructor releases lock_.
}


The guard mutex is only accessed in the initialization phase of 
the singleton. Once instance_ is set the guard does not need to be queried 
anymore.


Richard
___
Von: osg-users-boun...@lists.openscenegraph.org 
[mailto:osg-users-boun...@lists.openscenegraph.org] Im Auftrag von Robert 
Osfield

Gesendet: Dienstag, 17. März 2009 11:07

An: OpenSceneGraph Users
Betreff: Re: [osg-users] Multithreading crash 
duetoosgDb::Registry::instance()


2009/3/17 Schmidt, Richard 
http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf 
 

Could you explain what the above document is all about...

Robert.

___
osg-users mailing list
osg-users@lists.openscenegraph.org

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Multithreading crash due to osgDb::Registry::instance()

[I-Nixon, Anthony D]

I've encountered a crash when using CompositeViewer in Multithreaded
mode due to concurrent access to osgDb::Registry::instance().

The usage scenario is having two views (that have an empty scene graph -
since no data has been loaded, osgdb::Registry::instance() hasn't yet
been called).

On the first frame, each of the render threads calls
osgDb::Registry::instance(), and one gets back a null pointer (which is
kind of bad for an instance :-)

The fix for me is easy - just call osgDb::Registry::instance() sometime
before starting rendering, but a more general solution would be better,
of course.

This is with OSG 2.8.0 - although there don't appear to have been any
changes in this area in the trunk, either.

I've only confirmed this on Windows XP and Visual C++ 8. 




Anthony Nixon

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Using TerraPage database and osgSim::LineOfSightfor non-displayed scene graph - how to get nodes to page in?

[I-Nixon, Anthony D]

Okay, thanks Rob.

I was assuming that the DatabasePager should load the nodes, but it is
nice to have confirmation.  

I'll do some stepping. 

> -Original Message-
> From: Robert Osfield [mailto:robert.osfi...@gmail.com] 
> Sent: Tuesday, 23 December 2008 7:31 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Using TerraPage database and 
> osgSim::LineOfSightfor non-displayed scene graph - how to get 
> nodes to page in?
> 
> Hi Anthony,
> 
> I'm afraid I've never tried to combine TerraPage databases 
> with the osg::Sim lntersection classes, so can't point you in 
> any particular direction.  In theory the .txp plugin creates 
> PagedLOD's and then leverages the osgDB::DatabasePager for 
> paging, so should be mappable across to how the osgSim 
> intersections classes read tiles in, but clearly there must 
> be something amiss as to what it might be I can't say.  
> You'll need to step through the .txp plugin with a debug to 
> see what the difference are between when it's paged by the 
> normal viewer vs the osgSim intersection classes.
> 
> Robert.
> 
> On Mon, Dec 22, 2008 at 10:34 PM, I-Nixon, Anthony D 
>  wrote:
> > Hello everyone:
> >
> > I'm trying to compute LOS on a scene graph that is not 
> being displayed 
> > (this is for "offline" analysis).
> >
> > Code looks a bit like this:
> >
> >
> >osgDB::FilePathList
> > filePath(osgDB::Registry::instance()->getDataFilePathList());
> >filePath.push_front(dirContainingTerrain);
> >osgDB::Registry::instance()->setDataFilePathList(filePath);
> >
> >osg::ref_ptr terrain = 
> > osgDB::readNodeFile("archive.txp");
> >
> >osgSim::LineOfSight::Intersections ints = 
> > osgSim::LineOfSight::computeIntersections(terrain.get(), aPoint, 
> > theOtherPoint);
> >
> > The issue is that the TerraPage loader doesn't seem to load in the 
> > paged LODs.  Is there something I need to do to trigger this?  The 
> > above code works fine for ive based Paged terrain 
> (generated using osgdem).
> >
> > The LineOfSight is functioning as expected if the scene graph is 
> > displayed in a viewer.
> >
> > Any pointers would be most appreciated.
> >
> > This is with OSG 2.6.1
> >
> > Thanks in advance.
> >
> > // Anthony Nixon
> > // Modelling & Simulation Architect
> > // Systems Analysis Laboratory
> > // Boeing Defence Australia
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.
> > org
> >
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-opensce
> negraph.org
> 
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Using TerraPage database and osgSim::LineOfSight for non-displayed scene graph - how to get nodes to page in?

[I-Nixon, Anthony D]

Hello everyone:

I'm trying to compute LOS on a scene graph that is not being displayed
(this is for "offline" analysis).

Code looks a bit like this:


osgDB::FilePathList
filePath(osgDB::Registry::instance()->getDataFilePathList());
filePath.push_front(dirContainingTerrain);
osgDB::Registry::instance()->setDataFilePathList(filePath);

osg::ref_ptr terrain =
osgDB::readNodeFile("archive.txp");

osgSim::LineOfSight::Intersections ints =
osgSim::LineOfSight::computeIntersections(terrain.get(), aPoint,
theOtherPoint);

The issue is that the TerraPage loader doesn't seem to load in the paged
LODs.  Is there something I need to do to trigger this?  The above code
works fine for ive based Paged terrain (generated using osgdem).

The LineOfSight is functioning as expected if the scene graph is
displayed in a viewer.

Any pointers would be most appreciated.

This is with OSG 2.6.1

Thanks in advance.

// Anthony Nixon
// Modelling & Simulation Architect
// Systems Analysis Laboratory
// Boeing Defence Australia

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org