Re: [osg-users] Bug in osgGA::EventQueue?
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 anthony.d.ni...@boeing.com 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::ScopedLockOpenThreads::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
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?
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::ScopedLockOpenThreads::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
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
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 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()
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 richard.schm...@eads.com
mailto:richard.schm...@eads.com
http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf
http://www.cs.wustl.edu/%7Eschmidt/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_).
GuardMutex 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
[osg-users] Multithreading crash due to osgDb::Registry::instance()
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] Multithreading crashduetoosgDb::Registry::instance()
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
richard.schm...@eads.com 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_).
GuardMutex 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 richard.schm...@eads.com
http://www.cs.wustl.edu/~schmidt/PDF/DC-Locking.pdf
http://www.cs.wustl.edu/%7Eschmidt/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
Re: [osg-users] Using TerraPage database and osgSim::LineOfSightfor non-displayed scene graph - how to get nodes to page in?
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 anthony.d.ni...@boeing.com 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_ptrosg::Node 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?
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_ptrosg::Node 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
