Re: [osg-users] dotosg wrappers not thread safe

2012-06-05 Thread Mikhail I. Izmestev 

Hi,

Here is code to reproduce crash:

code
#include osgDB/ReadFile
#include OpenThreads/Mutex
#include OpenThreads/Thread
#include OpenThreads/Condition

static OpenThreads::Condition s_cond;
static OpenThreads::Mutex s_mtx;

class ReadThread : public OpenThreads::Thread
{
public:
  ReadThread() {}

  void run()
  {
{
  OpenThreads::ScopedLockOpenThreads::Mutex lock(s_mtx);
  s_cond.wait(s_mtx);
}
osg::ref_ptrosg::Node node = osgDB::readNodeFile(cow.osg);
  }
};

int main()
{
  ReadThread t1, t2;
  t1.start();
  t2.start();

//  OpenThreads::Thread::microSleep(500);

  {
OpenThreads::ScopedLockOpenThreads::Mutex lock(s_mtx);
s_cond.broadcast();
  }

  t1.join();
  t2.join();
  return 0;
}
/code

To reproduce you can use this script:
code
#!/usr/bin/env bash

while(true); do
./test
done
/code

But while testing fix I have new crash at:
ntdll!RtlReportCriticalFailure+0x62
ntdll!RtlpReportHeapFailure+0x26
ntdll!RtlpHeapHandleError+0x12
ntdll!RtlpLogHeapFailure+0xa4
ntdll!RtlpAnalyzeHeapFailure+0x3a8
ntdll!RtlpFreeHeap+0x141f
ntdll!RtlFreeHeap+0x1a6
kernel32!HeapFree+0xa
MSVCR90!free+0x1c
MSVCP90!std::basic_stringchar,std::char_traitschar,std::allocatorchar
MSVCP90!std::basic_stringchar,std::char_traitschar,std::allocatorchar
MSVCP90!std::operator+char,std::char_traitschar,std::allocatorchar
osg92_osgDB!osgDB::Registry::createLibraryNameForExtension+0x34b
osg92_osgDB!osgDB::Registry::createLibraryNameForFile+0x42
osg92_osgDB!osgDB::Registry::read+0x1608
osg92_osgDB!osgDB::Registry::readImplementation+0x34c
osg92_osgDB!osgDB::Registry::readNodeImplementation+0x6a
osg92_osgDB!osgDB::Registry::readNode+0xfc
osg92_osgDB!osgDB::readNodeFile+0x4e
dotosgcrash!ReadThread::run+0x79

code:
std::string Registry::createLibraryNameForExtension(const std::string ext)
{
std::string lowercase_ext;
for(std::string::const_iterator sitr=ext.begin();
sitr!=ext.end();
++sitr)
{
lowercase_ext.push_back(tolower(*sitr));
}

ExtensionAliasMap::iterator itr=_extAliasMap.find(lowercase_ext);
if (itr!=_extAliasMap.end()  ext != itr-second) return 
createLibraryNameForExtension(itr-second);


#if defined(OSG_JAVA_BUILD)
static std::string prepend = 
std::string(osgPlugins-)+std::string(osgGetVersion())+std::string(/java);

#else
static std::string prepend = 
std::string(osgPlugins-)+std::string(osgGetVersion())+std::string(/);

#endif
[..]

same design:
static std::string prepend = 
std::string(osgPlugins-)+std::string(osgGetVersion())+std::string(/);


Mikhail.

04.06.2012 13:17, Mikhail I. Izmestev написал:

Hi Robert,

It is hard to reproduce this problem (as any thread safety problem) in
same state as previous.

I have another crash with same problem at:
ntdll!RtlEnterCriticalSection+0x6
ot12_OpenThreads!OpenThreads::Mutex::lock+0xe
osgdb_deprecated_osg!initGLNames+0x66
osgdb_deprecated_osg!StateSet_readLocalData+0x4f
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObjectOfType+0x9eb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObjectOfType+0x28
osgdb_deprecated_osg!Node_readLocalData+0x349
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_osg!OSGReaderWriter::readNode+0xfe
osgdb_osg!OSGReaderWriter::readNode+0x31c
osg80_osgDB!osgDB::Registry::ReadNodeFunctor::doRead+0x28
osg80_osgDB!osgDB::Registry::read+0x5e4
osg80_osgDB!osgDB::Registry::readImplementation+0x34c
osg80_osgDB!osgDB::Registry::readNodeImplementation+0x6a
osg80_osgDB!osgDB::Registry::readNode+0xfc
osg80_osgDB!osgDB::readNodeFile+0x4e

crashed code:
int Mutex::lock() {
Win32MutexPrivateData *pd =
static_castWin32MutexPrivateData*(_prvData);

#ifdef USE_CRITICAL_SECTION

// Block until we can take this lock.
EnterCriticalSection( (pd-_cs) );  CRASH HERE

return 0;
[...]

pd-_cs == NULL

in this case problem at
void initGLNames()
{
static bool first_time = true;
if (!first_time) return;

static OpenThreads::Mutex s_initGLNames;
OpenThreads::ScopedLockOpenThreads::Mutex lock(s_initGLNames);

[...]

There is lot of other places with same design:
AnimationPath.cpp:201: static osg::ref_ptrosg::AnimationPath s_path =
new osg::AnimationPath;
CoordinateSystemNode.cpp:48: static ref_ptrEllipsoidModel
s_ellipsoidModel = new EllipsoidModel;
Drawable.cpp:30: static ref_ptrStateSet s_drawstate = new osg::StateSet;
Node.cpp:77: static ref_ptrStateSet s_drawstate = new osg::StateSet;
Node.cpp:85: static ref_ptrNodeCallback s_nodecallback = new
osg::NodeCallback;
NodeCallback.cpp:31: static osg::ref_ptrNodeCallback s_nc = new
NodeCallback;
OccluderNode.cpp:30: static ref_ptrConvexPlanarOccluder s_occluder =
new ConvexPlanarOccluder;
Sequence.cpp:26:static bool Sequence_matchLoopMode(const char* str,
Sequence.cpp:45:static const char*
Sequence_getLoopMode(Sequence::LoopMode mode)
Sequence.cpp:57:static bool Sequence_matchSeqMode(const char* str,
Sequence.cpp:76:static const char

Re: [osg-users] dotosg wrappers not thread safe

2012-06-05 Thread Mikhail I. Izmestev 

Hi Robert,

I tried to reproduce this problem on linux but without luck.

gcc use more complex method of initialization of static variables at 
function scope.


So problem is only with MSVC 2008 (not sure about newer versions).

Mikhail.

05.06.2012 10:39, Mikhail I. Izmestev написал:

Hi,

Here is code to reproduce crash:

code
#include osgDB/ReadFile
#include OpenThreads/Mutex
#include OpenThreads/Thread
#include OpenThreads/Condition

static OpenThreads::Condition s_cond;
static OpenThreads::Mutex s_mtx;

class ReadThread : public OpenThreads::Thread
{
public:
ReadThread() {}

void run()
{
{
OpenThreads::ScopedLockOpenThreads::Mutex lock(s_mtx);
s_cond.wait(s_mtx);
}
osg::ref_ptrosg::Node node = osgDB::readNodeFile(cow.osg);
}
};

int main()
{
ReadThread t1, t2;
t1.start();
t2.start();

// OpenThreads::Thread::microSleep(500);

{
OpenThreads::ScopedLockOpenThreads::Mutex lock(s_mtx);
s_cond.broadcast();
}

t1.join();
t2.join();
return 0;
}
/code

To reproduce you can use this script:
code
#!/usr/bin/env bash

while(true); do
./test
done
/code

But while testing fix I have new crash at:
ntdll!RtlReportCriticalFailure+0x62
ntdll!RtlpReportHeapFailure+0x26
ntdll!RtlpHeapHandleError+0x12
ntdll!RtlpLogHeapFailure+0xa4
ntdll!RtlpAnalyzeHeapFailure+0x3a8
ntdll!RtlpFreeHeap+0x141f
ntdll!RtlFreeHeap+0x1a6
kernel32!HeapFree+0xa
MSVCR90!free+0x1c
MSVCP90!std::basic_stringchar,std::char_traitschar,std::allocatorchar
MSVCP90!std::basic_stringchar,std::char_traitschar,std::allocatorchar
MSVCP90!std::operator+char,std::char_traitschar,std::allocatorchar
osg92_osgDB!osgDB::Registry::createLibraryNameForExtension+0x34b
osg92_osgDB!osgDB::Registry::createLibraryNameForFile+0x42
osg92_osgDB!osgDB::Registry::read+0x1608
osg92_osgDB!osgDB::Registry::readImplementation+0x34c
osg92_osgDB!osgDB::Registry::readNodeImplementation+0x6a
osg92_osgDB!osgDB::Registry::readNode+0xfc
osg92_osgDB!osgDB::readNodeFile+0x4e
dotosgcrash!ReadThread::run+0x79

code:
std::string Registry::createLibraryNameForExtension(const std::string ext)
{
std::string lowercase_ext;
for(std::string::const_iterator sitr=ext.begin();
sitr!=ext.end();
++sitr)
{
lowercase_ext.push_back(tolower(*sitr));
}

ExtensionAliasMap::iterator itr=_extAliasMap.find(lowercase_ext);
if (itr!=_extAliasMap.end()  ext != itr-second) return
createLibraryNameForExtension(itr-second);

#if defined(OSG_JAVA_BUILD)
static std::string prepend =
std::string(osgPlugins-)+std::string(osgGetVersion())+std::string(/java);

#else
static std::string prepend =
std::string(osgPlugins-)+std::string(osgGetVersion())+std::string(/);
#endif
[..]

same design:
static std::string prepend =
std::string(osgPlugins-)+std::string(osgGetVersion())+std::string(/);

Mikhail.

04.06.2012 13:17, Mikhail I. Izmestev написал:

Hi Robert,

It is hard to reproduce this problem (as any thread safety problem) in
same state as previous.

I have another crash with same problem at:
ntdll!RtlEnterCriticalSection+0x6
ot12_OpenThreads!OpenThreads::Mutex::lock+0xe
osgdb_deprecated_osg!initGLNames+0x66
osgdb_deprecated_osg!StateSet_readLocalData+0x4f
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObjectOfType+0x9eb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObjectOfType+0x28
osgdb_deprecated_osg!Node_readLocalData+0x349
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_osg!OSGReaderWriter::readNode+0xfe
osgdb_osg!OSGReaderWriter::readNode+0x31c
osg80_osgDB!osgDB::Registry::ReadNodeFunctor::doRead+0x28
osg80_osgDB!osgDB::Registry::read+0x5e4
osg80_osgDB!osgDB::Registry::readImplementation+0x34c
osg80_osgDB!osgDB::Registry::readNodeImplementation+0x6a
osg80_osgDB!osgDB::Registry::readNode+0xfc
osg80_osgDB!osgDB::readNodeFile+0x4e

crashed code:
int Mutex::lock() {
Win32MutexPrivateData *pd =
static_castWin32MutexPrivateData*(_prvData);

#ifdef USE_CRITICAL_SECTION

// Block until we can take this lock.
EnterCriticalSection( (pd-_cs) );  CRASH HERE

return 0;
[...]

pd-_cs == NULL

in this case problem at
void initGLNames()
{
static bool first_time = true;
if (!first_time) return;

static OpenThreads::Mutex s_initGLNames;
OpenThreads::ScopedLockOpenThreads::Mutex lock(s_initGLNames);

[...]

There is lot of other places with same design:
AnimationPath.cpp:201: static osg::ref_ptrosg::AnimationPath s_path =
new osg::AnimationPath;
CoordinateSystemNode.cpp:48: static ref_ptrEllipsoidModel
s_ellipsoidModel = new EllipsoidModel;
Drawable.cpp:30: static ref_ptrStateSet s_drawstate = new
osg::StateSet;
Node.cpp:77: static ref_ptrStateSet s_drawstate = new osg::StateSet;
Node.cpp:85: static ref_ptrNodeCallback s_nodecallback = new
osg::NodeCallback;
NodeCallback.cpp:31: static osg::ref_ptrNodeCallback s_nc = new
NodeCallback;
OccluderNode.cpp:30: static ref_ptrConvexPlanarOccluder s_occluder =
new ConvexPlanarOccluder;
Sequence.cpp:26:static bool Sequence_matchLoopMode(const char* str,
Sequence.cpp:45:static const char

Re: [osg-users] dotosg wrappers not thread safe

2012-06-05 Thread Mikhail I. Izmestev 

Hi,

MSVC not support thread safe initialization of static variables at 
function scope.


GCC by default generate thread safe code, but it can generate code like 
MSVC by passing -fno-threadsafe-statics option.


So you can reproduce crash if add -fno-threadsafe-statics option to 
CXX_FLAGS.


Problem will reproduced very easy.

Mikhail.

05.06.2012 13:31, Mikhail I. Izmestev написал:

Hi Robert,

I tried to reproduce this problem on linux but without luck.

gcc use more complex method of initialization of static variables at
function scope.

So problem is only with MSVC 2008 (not sure about newer versions).

Mikhail.

05.06.2012 10:39, Mikhail I. Izmestev написал:

Hi,

Here is code to reproduce crash:

code
#include osgDB/ReadFile
#include OpenThreads/Mutex
#include OpenThreads/Thread
#include OpenThreads/Condition

static OpenThreads::Condition s_cond;
static OpenThreads::Mutex s_mtx;

class ReadThread : public OpenThreads::Thread
{
public:
ReadThread() {}

void run()
{
{
OpenThreads::ScopedLockOpenThreads::Mutex lock(s_mtx);
s_cond.wait(s_mtx);
}
osg::ref_ptrosg::Node node = osgDB::readNodeFile(cow.osg);
}
};

int main()
{
ReadThread t1, t2;
t1.start();
t2.start();

// OpenThreads::Thread::microSleep(500);

{
OpenThreads::ScopedLockOpenThreads::Mutex lock(s_mtx);
s_cond.broadcast();
}

t1.join();
t2.join();
return 0;
}
/code

To reproduce you can use this script:
code
#!/usr/bin/env bash

while(true); do
./test
done
/code

But while testing fix I have new crash at:
ntdll!RtlReportCriticalFailure+0x62
ntdll!RtlpReportHeapFailure+0x26
ntdll!RtlpHeapHandleError+0x12
ntdll!RtlpLogHeapFailure+0xa4
ntdll!RtlpAnalyzeHeapFailure+0x3a8
ntdll!RtlpFreeHeap+0x141f
ntdll!RtlFreeHeap+0x1a6
kernel32!HeapFree+0xa
MSVCR90!free+0x1c
MSVCP90!std::basic_stringchar,std::char_traitschar,std::allocatorchar

MSVCP90!std::basic_stringchar,std::char_traitschar,std::allocatorchar

MSVCP90!std::operator+char,std::char_traitschar,std::allocatorchar
osg92_osgDB!osgDB::Registry::createLibraryNameForExtension+0x34b
osg92_osgDB!osgDB::Registry::createLibraryNameForFile+0x42
osg92_osgDB!osgDB::Registry::read+0x1608
osg92_osgDB!osgDB::Registry::readImplementation+0x34c
osg92_osgDB!osgDB::Registry::readNodeImplementation+0x6a
osg92_osgDB!osgDB::Registry::readNode+0xfc
osg92_osgDB!osgDB::readNodeFile+0x4e
dotosgcrash!ReadThread::run+0x79

code:
std::string Registry::createLibraryNameForExtension(const std::string
ext)
{
std::string lowercase_ext;
for(std::string::const_iterator sitr=ext.begin();
sitr!=ext.end();
++sitr)
{
lowercase_ext.push_back(tolower(*sitr));
}

ExtensionAliasMap::iterator itr=_extAliasMap.find(lowercase_ext);
if (itr!=_extAliasMap.end()  ext != itr-second) return
createLibraryNameForExtension(itr-second);

#if defined(OSG_JAVA_BUILD)
static std::string prepend =
std::string(osgPlugins-)+std::string(osgGetVersion())+std::string(/java);


#else
static std::string prepend =
std::string(osgPlugins-)+std::string(osgGetVersion())+std::string(/);
#endif
[..]

same design:
static std::string prepend =
std::string(osgPlugins-)+std::string(osgGetVersion())+std::string(/);

Mikhail.

04.06.2012 13:17, Mikhail I. Izmestev написал:

Hi Robert,

It is hard to reproduce this problem (as any thread safety problem) in
same state as previous.

I have another crash with same problem at:
ntdll!RtlEnterCriticalSection+0x6
ot12_OpenThreads!OpenThreads::Mutex::lock+0xe
osgdb_deprecated_osg!initGLNames+0x66
osgdb_deprecated_osg!StateSet_readLocalData+0x4f
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObjectOfType+0x9eb

osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObjectOfType+0x28
osgdb_deprecated_osg!Node_readLocalData+0x349
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_osg!OSGReaderWriter::readNode+0xfe
osgdb_osg!OSGReaderWriter::readNode+0x31c
osg80_osgDB!osgDB::Registry::ReadNodeFunctor::doRead+0x28
osg80_osgDB!osgDB::Registry::read+0x5e4
osg80_osgDB!osgDB::Registry::readImplementation+0x34c
osg80_osgDB!osgDB::Registry::readNodeImplementation+0x6a
osg80_osgDB!osgDB::Registry::readNode+0xfc
osg80_osgDB!osgDB::readNodeFile+0x4e

crashed code:
int Mutex::lock() {
Win32MutexPrivateData *pd =
static_castWin32MutexPrivateData*(_prvData);

#ifdef USE_CRITICAL_SECTION

// Block until we can take this lock.
EnterCriticalSection( (pd-_cs) );  CRASH HERE

return 0;
[...]

pd-_cs == NULL

in this case problem at
void initGLNames()
{
static bool first_time = true;
if (!first_time) return;

static OpenThreads::Mutex s_initGLNames;
OpenThreads::ScopedLockOpenThreads::Mutex lock(s_initGLNames);

[...]

There is lot of other places with same design:
AnimationPath.cpp:201: static osg::ref_ptrosg::AnimationPath s_path =
new osg::AnimationPath;
CoordinateSystemNode.cpp:48: static ref_ptrEllipsoidModel
s_ellipsoidModel = new EllipsoidModel;
Drawable.cpp:30: static ref_ptrStateSet s_drawstate = new
osg::StateSet;
Node.cpp:77: static

Re: [osg-users] dotosg wrappers not thread safe

2012-06-04 Thread Mikhail I. Izmestev 

Hi Robert,

It is hard to reproduce this problem (as any thread safety problem) in 
same state as previous.


I have another crash with same problem at:
ntdll!RtlEnterCriticalSection+0x6
ot12_OpenThreads!OpenThreads::Mutex::lock+0xe
osgdb_deprecated_osg!initGLNames+0x66
osgdb_deprecated_osg!StateSet_readLocalData+0x4f
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObjectOfType+0x9eb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObjectOfType+0x28
osgdb_deprecated_osg!Node_readLocalData+0x349
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_osg!OSGReaderWriter::readNode+0xfe
osgdb_osg!OSGReaderWriter::readNode+0x31c
osg80_osgDB!osgDB::Registry::ReadNodeFunctor::doRead+0x28
osg80_osgDB!osgDB::Registry::read+0x5e4
osg80_osgDB!osgDB::Registry::readImplementation+0x34c
osg80_osgDB!osgDB::Registry::readNodeImplementation+0x6a
osg80_osgDB!osgDB::Registry::readNode+0xfc
osg80_osgDB!osgDB::readNodeFile+0x4e

crashed code:
int Mutex::lock() {
Win32MutexPrivateData *pd =
static_castWin32MutexPrivateData*(_prvData);

#ifdef USE_CRITICAL_SECTION

// Block until we can take this lock.
EnterCriticalSection( (pd-_cs) );  CRASH HERE

return 0;
[...]

pd-_cs == NULL

in this case problem at
void initGLNames()
{
static bool first_time = true;
if (!first_time) return;

static OpenThreads::Mutex s_initGLNames;
OpenThreads::ScopedLockOpenThreads::Mutex lock(s_initGLNames);

[...]

There is lot of other places with same design:
AnimationPath.cpp:201:static osg::ref_ptrosg::AnimationPath s_path 
= new osg::AnimationPath;
CoordinateSystemNode.cpp:48:static ref_ptrEllipsoidModel 
s_ellipsoidModel = new EllipsoidModel;
Drawable.cpp:30:static ref_ptrStateSet s_drawstate = new 
osg::StateSet;

Node.cpp:77:static ref_ptrStateSet s_drawstate = new osg::StateSet;
Node.cpp:85:static ref_ptrNodeCallback s_nodecallback = new 
osg::NodeCallback;
NodeCallback.cpp:31:static osg::ref_ptrNodeCallback s_nc = new 
NodeCallback;
OccluderNode.cpp:30:static ref_ptrConvexPlanarOccluder s_occluder 
= new ConvexPlanarOccluder;

Sequence.cpp:26:static bool Sequence_matchLoopMode(const char* str,
Sequence.cpp:45:static const char* 
Sequence_getLoopMode(Sequence::LoopMode mode)

Sequence.cpp:57:static bool Sequence_matchSeqMode(const char* str,
Sequence.cpp:76:static const char* 
Sequence_getSeqMode(Sequence::SequenceMode mode)
StateAttribute.cpp:32:static ref_ptrStateAttributeCallback 
s_callback = new osg::StateAttributeCallback;

StateSet.cpp:80:static bool first_time = true;
StateSet.cpp:83:static OpenThreads::Mutex s_initGLNames;
StateSet.cpp:362:static ref_ptrStateSet::Callback s_callback = new 
osg::StateSet::Callback;
Uniform.cpp:212:static ref_ptrUniform::Callback s_callback = new 
osg::Uniform::Callback;


Mikhail.

04.06.2012 12:44, Robert Osfield написал:

Hi Mikhail,

I have moved the static into the global scope of the
osgWrappers/deprecated-dotosg/Drawable.cpp, file attached, could try
it out?

Robert.

On 2 June 2012 11:12, Mikhail I. Izmestevizmmish...@gmail.com  wrote:

Hi,

I noticed crashing in dotosg wrappers when try to use osgDB::readNodeFile
from multiple threads.
Crash occurs when I try to load .osg file from two threads.

For example callstack of crashed thread:
osg80_osgDB!concrete_wrapper::matches+0x4
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObjectOfType+0x527
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObjectOfType+0x28
osgdb_deprecated_osg!Drawable_readLocalData+0xa1
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readDrawable+0xe1
osgdb_deprecated_osg!Geode_readLocalData+0x90
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_deprecated_osg!Group_readLocalData+0x71
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_deprecated_osg!Group_readLocalData+0x71
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_osg!OSGReaderWriter::readNode+0xfe
osgdb_osg!OSGReaderWriter::readNode+0x31c
osg80_osgDB!osgDB::Registry::ReadNodeFunctor::doRead+0x28
osg80_osgDB!osgDB::Registry::read+0x5e4
osg80_osgDB!osgDB::Registry::readImplementation+0x34c
osg80_osgDB!osgDB::Registry::readNodeImplementation+0x6a
osg80_osgDB!osgDB::Registry::readNode+0xfc
osg80_osgDB!osgDB::readNodeFile+0x4e
[...]

second thread callstack:
msvcp90!std::basic_istreamchar,std::char_traitschar
msvcp90!std::basic_istreamchar,std::char_traitschar
osg80_osgDB!osgDB::FieldReader::_readField+0x3f8
osg80_osgDB!osgDB::FieldReaderIterator::field+0x19d
osgdb_deprecated_osg!Array_readLocalData+0xbfb

[osg-users] dotosg wrappers not thread safe

2012-06-02 Thread Mikhail I. Izmestev 

Hi,

I noticed crashing in dotosg wrappers when try to use osgDB::readNodeFile from 
multiple threads.
Crash occurs when I try to load .osg file from two threads.

For example callstack of crashed thread:
osg80_osgDB!concrete_wrapper::matches+0x4
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObjectOfType+0x527
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObjectOfType+0x28
osgdb_deprecated_osg!Drawable_readLocalData+0xa1
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readDrawable+0xe1
osgdb_deprecated_osg!Geode_readLocalData+0x90
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_deprecated_osg!Group_readLocalData+0x71
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_deprecated_osg!Group_readLocalData+0x71
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_osg!OSGReaderWriter::readNode+0xfe
osgdb_osg!OSGReaderWriter::readNode+0x31c
osg80_osgDB!osgDB::Registry::ReadNodeFunctor::doRead+0x28
osg80_osgDB!osgDB::Registry::read+0x5e4
osg80_osgDB!osgDB::Registry::readImplementation+0x34c
osg80_osgDB!osgDB::Registry::readNodeImplementation+0x6a
osg80_osgDB!osgDB::Registry::readNode+0xfc
osg80_osgDB!osgDB::readNodeFile+0x4e
[...]

second thread callstack:
msvcp90!std::basic_istreamchar,std::char_traitschar
msvcp90!std::basic_istreamchar,std::char_traitschar
osg80_osgDB!osgDB::FieldReader::_readField+0x3f8
osg80_osgDB!osgDB::FieldReaderIterator::field+0x19d
osgdb_deprecated_osg!Array_readLocalData+0xbfb
osgdb_deprecated_osg!Geometry_readLocalData+0x991
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readDrawable+0xe1
osgdb_deprecated_osg!Geode_readLocalData+0x90
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_deprecated_osg!Group_readLocalData+0x71
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_deprecated_osg!Group_readLocalData+0x9a
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_deprecated_osg!Group_readLocalData+0x9a
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_deprecated_osg!Group_readLocalData+0x71
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readObject+0x8fb
osg80_osgDB!osgDB::DeprecatedDotOsgWrapperManager::readNode+0xe1
osgdb_osg!OSGReaderWriter::readNode+0xfe
osgdb_osg!OSGReaderWriter::readNode+0x31c
osg80_osgDB!osgDB::Registry::ReadNodeFunctor::doRead+0x28
osg80_osgDB!osgDB::Registry::read+0x5e4
osg80_osgDB!osgDB::Registry::readImplementation+0x34c
osg80_osgDB!osgDB::Registry::readNodeImplementation+0x6a
osg80_osgDB!osgDB::Registry::readNode+0xfc
osg80_osgDB!osgDB::readNodeFile+0x4e
[...]

code:
struct concrete_wrapper: basic_type_wrapper
{
virtual ~concrete_wrapper() {}
concrete_wrapper(const osg::Object *myobj) : myobj_(myobj) {}
bool matches(const osg::Object *proto) const
{
return myobj_-isSameKindAs(proto);  CRASH HERE
}
const osg::Object *myobj_;
};

crash occurs because myobj_ is NULL.

myobj_ passed from osgdb_deprecated_osg!Drawable_readLocalData as s_drawstate

bool Drawable_readLocalData(Object obj, Input fr)
{
bool iteratorAdvanced = false;

Drawable drawable = static_castDrawable(obj);

static ref_ptrStateSet s_drawstate = new osg::StateSet;
if (StateSet* readState = 
static_castStateSet*(fr.readObjectOfType(*s_drawstate)))
{
drawable.setStateSet(readState);
iteratorAdvanced = true;
}
[...]


so problem is in
static ref_ptrStateSet s_drawstate = new osg::StateSet;

MSVC 2008 x64 compiler (maybe gcc too) generate this code as:

static bool s_drawstate_init = false;
static ref_ptrStateSet s_drawstate = NULL;

bool Drawable_readLocalData(Object obj, Input fr)
{
bool iteratorAdvanced = false;

Drawable drawable = static_castDrawable(obj);

if(!s_drawstate_init)
{
s_drawstate_init = true;
s_drawstate = new osg::StateSet;
}

if (StateSet* readState = 
static_castStateSet*(fr.readObjectOfType(*s_drawstate)))
{
drawable.setStateSet(readState);
iteratorAdvanced = true;
}
[...]


and this code is not thread safe as you can see.

Possible solution is to move static variables to global scope to avoid lazy 
initialization.


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

Re: [osg-users] How to correct remove objects from scene graph and destruct they not in render thread?

2012-02-17 Thread Mikhail I. Izmestev 

17.02.2012 16:11, Robert Osfield пишет:

Hi Mikhail,

If you want to remove elements from the scene graph but delay
destruction to be done in a background thread the way to do it take a
ref_ptr  to the subgraph you want to remove to prevent it from being
deleted, then remove the subgraph from the scene within the update
phase of the viewer frame, then pass this ref_ptr  to the background
thread.  Personally I wouldn't use co-opt the DatabasePager for doing
this - although it does supports this already, conceptually it doesn't
make for a clean application.



Yes, I'm doing this as you explained.
But you are not answer how to avoid crash in case described by me.

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

[osg-users] How to correct remove objects from scene graph and destruct they not in render thread?

2012-02-16 Thread Mikhail I. Izmestev 

Hi,

To remove heavy in destruction objects (which will free large buffers 
and etc.) I use method like in DatabasePager - hold object references 
and pass they to another thread for destructing.


But there is one case which cause crash.

(root)
   |
  (some nodes)
 (...)
  ||
   (nodeA)  (nodeB)
  \/
\/
   (nodeC)
  |
(...)
  |
   (nodeD)

So we have nodeC with two parents, and in some moment we want to delete 
subgraph with nodeA.
We remove from graph parents of nodeA and hold it reference to be 
destructed later in another thread.
Another thread decrease reference for parents of nodeA and initialize 
destruction, so nodeA have no more references and it want to be deleted, 
it inform children about that and request to remove it from parent list.
But in render thread we still render main graph and it traverse nodeC, 
but someone like nodeD changed it's matrix, this process require to 
dirtyBound, and dirtyBound inform all parents about this and tries to 
walk backward for all parents and nodeA too.


So one thread iterate _parent vector, second thread change this vector, 
and in result CRASH!


Looks like DatabasePager affects this problem too.

What you can advice in this case?

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

Re: [osg-users] VBO Bug ?

2011-10-12 Thread Mikhail I. Izmestev 
12.10.2011 20:45, Wojciech Lewandowski wrote:
 So if you are on Linux and have a minute please let me know how the test 
 passed on your machine ;-) 

Hi, Wojtek,

gentoo x86_64
GeForce 9600 GT
270.41.06

good result

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

[osg-users] What status of osgManipulator::Constraint?

2011-05-25 Thread Mikhail I. Izmestev 

Hi,

I have discovered some problems with osgManipulator::Constraint such as 
methods which will never called:

bool constrain(TranslateInLineCommand command) const
bool constrain(TranslateInPlaneCommand command) const
bool constrain(Scale1DCommand command) const
bool constrain(Scale2DCommand command) const
bool constrain(ScaleUniformCommand command) const

Some bugs in osgManipulatro::Dragger's methods addConstraint and 
removeConstraint.


So is osgManipulator::Constraint deprecated or it needed in submissions?

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

Re: [osg-users] What status of osgManipulator::Constraint?

2011-05-25 Thread Mikhail I. Izmestev 

Hi Robert,

Yes, I'm talking about latest svn/trunk version.

Bug in Dragger::addConstraint using = instead ==

void Dragger::addConstraint(Constraint* constraint)
{
// check to make sure constaint hasn't already been attached.
for(Constraints::iterator itr = _constraints.begin();
itr != _constraints.end();
++itr)
{
if (*itr = constraint) return;
}

_constraints.push_back(constraint);
}

same bug in Dragger::removeConstraint.

About constrain methods of Constraint class, Dragger::dispatch can only 
call bool constrain(MotionCommand) const


void Dragger::dispatch(MotionCommand command)
{
// apply any constraints
for(Constraints::iterator itr = _constraints.begin();
itr != _constraints.end();
++itr)
{
(*itr)-constrain(command);
}

// move self
getParentDragger()-receive(command);


for(DraggerCallbacks::iterator itr = 
getParentDragger()-getDraggerCallbacks().begin();

itr != getParentDragger()-getDraggerCallbacks().end();
++itr)
{
(*itr)-receive(command);
}
}

Same feature/bug with DraggerCallback::receive methods.

Mikhail.

25.05.2011 10:52, Robert Osfield wrote:

Hi Mikhail,

I'm not the original author of osgManipulator, and alas, the original
author hasn't contributed since submitting, so it's now down the us to
maintain it.  I did some updates to it last year to fix some issue,
but can't claim to be an expert and certainly can't off the top of my
head make too much sense of your email just based on method names.  I
also don't know if you are referring to svn/trunk, 2.9.x or a previous
stable release.  I would suggest moving to svn/trunk or a recent 2.9.x
dev release for discussion purposes as these contain the improvements
I made.

Robert.

On Wed, May 25, 2011 at 7:13 AM, Mikhail I. Izmestev
izmmish...@gmail.com  wrote:

Hi,

I have discovered some problems with osgManipulator::Constraint such as
methods which will never called:
bool constrain(TranslateInLineCommand  command) const
bool constrain(TranslateInPlaneCommand  command) const
bool constrain(Scale1DCommand  command) const
bool constrain(Scale2DCommand  command) const
bool constrain(ScaleUniformCommand  command) const

Some bugs in osgManipulatro::Dragger's methods addConstraint and
removeConstraint.

So is osgManipulator::Constraint deprecated or it needed in submissions?

Mikhail.
___
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

Re: [osg-users] What status of osgManipulator::Constraint?

2011-05-25 Thread Mikhail I. Izmestev 

Hi Robert,

25.05.2011 11:53, Robert Osfield wrote:

Hi Mikhail,

Thanks for the explanation.  Could you post fixes to osg-submissions
so I can review them and merge the bug fixes.

I'm not yet clear on the disaptch issue, is it that any sublcass from
MotionCommand will be ast to MotionCommand and then handled by all the
contraints as a MotionCommand rather than the subclass?  If so then
this is a design issue rather than a local bug.


For example you can take a look to RotateCylinderDragger, it create 
Rotate3DCommand and pass it to dispatch method.


Only for that reason I believed that Constraint is deprecated.



Cheers,
Robert.

On Wed, May 25, 2011 at 8:08 AM, Mikhail I. Izmestev
izmmish...@gmail.com  wrote:

Hi Robert,

Yes, I'm talking about latest svn/trunk version.

Bug in Dragger::addConstraint using = instead ==

void Dragger::addConstraint(Constraint* constraint)
{
// check to make sure constaint hasn't already been attached.
for(Constraints::iterator itr = _constraints.begin();
itr != _constraints.end();
++itr)
{
if (*itr = constraint) return;
}

_constraints.push_back(constraint);
}

same bug in Dragger::removeConstraint.

About constrain methods of Constraint class, Dragger::dispatch can only call
bool constrain(MotionCommand) const

void Dragger::dispatch(MotionCommand  command)
{
// apply any constraints
for(Constraints::iterator itr = _constraints.begin();
itr != _constraints.end();
++itr)
{
(*itr)-constrain(command);
}

// move self
getParentDragger()-receive(command);


for(DraggerCallbacks::iterator itr =
getParentDragger()-getDraggerCallbacks().begin();
itr != getParentDragger()-getDraggerCallbacks().end();
++itr)
{
(*itr)-receive(command);
}
}

Same feature/bug with DraggerCallback::receive methods.

Mikhail.

25.05.2011 10:52, Robert Osfield wrote:


Hi Mikhail,

I'm not the original author of osgManipulator, and alas, the original
author hasn't contributed since submitting, so it's now down the us to
maintain it.  I did some updates to it last year to fix some issue,
but can't claim to be an expert and certainly can't off the top of my
head make too much sense of your email just based on method names.  I
also don't know if you are referring to svn/trunk, 2.9.x or a previous
stable release.  I would suggest moving to svn/trunk or a recent 2.9.x
dev release for discussion purposes as these contain the improvements
I made.

Robert.

On Wed, May 25, 2011 at 7:13 AM, Mikhail I. Izmestev
izmmish...@gmail.comwrote:


Hi,

I have discovered some problems with osgManipulator::Constraint such as
methods which will never called:
bool constrain(TranslateInLineCommandcommand) const
bool constrain(TranslateInPlaneCommandcommand) const
bool constrain(Scale1DCommandcommand) const
bool constrain(Scale2DCommandcommand) const
bool constrain(ScaleUniformCommandcommand) const

Some bugs in osgManipulatro::Dragger's methods addConstraint and
removeConstraint.

So is osgManipulator::Constraint deprecated or it needed in submissions?

Mikhail.
___
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 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] What status of osgManipulator::Constraint?

2011-05-25 Thread Mikhail I. Izmestev 

25.05.2011 12:29, Robert Osfield wrote:

Hi Mikhail,

On Wed, May 25, 2011 at 9:10 AM, Mikhail I. Izmestev
izmmish...@gmail.com  wrote:

For example you can take a look to RotateCylinderDragger, it create
Rotate3DCommand and pass it to dispatch method.


I'm afraid this doesn't explain what the problem is.  Could you please
explain the mechanics of the problem rather than just throw out
various class names as I can't second guess what problems you have
identified.

Robert.


Ok, Constraint class have methods

virtual bool constrain(MotionCommand) const
virtual bool constrain(TranslateInLineCommand command) const
virtual bool constrain(TranslateInPlaneCommand command) const
virtual bool constrain(Scale1DCommand command) const
virtual bool constrain(Scale2DCommand command) const
virtual bool constrain(ScaleUniformCommand command) const


And DraggerCallback class have methods

virtual bool receive(const MotionCommand)
virtual bool receive(const TranslateInLineCommand command)
virtual bool receive(const TranslateInPlaneCommand command)
virtual bool receive(const Scale1DCommand command)
virtual bool receive(const Scale2DCommand command)
virtual bool receive(const ScaleUniformCommand command)
virtual bool receive(const Rotate3DCommand command)

piece of code of RotateCylinderDragger::handle
code
...
osg::ref_ptrRotate3DCommand cmd = new Rotate3DCommand();
cmd-setStage(MotionCommand::MOVE);
cmd-setLocalToWorldAndWorldToLocal(_startLocalToWorld,_startWorldToLocal);
cmd-setRotation(rotation);

// Dispatch command.
dispatch(*cmd);
...
/code

As you can see there is used Rotate3DCommand, what we would expect from 
DraggerCallback attached to this Dragger, call of

bool receive(const Rotate3DCommand command)
or
bool receive(const MotionCommand)
?

Now see dispatch method
void Dragger::dispatch(MotionCommand command)
{
// apply any constraints
for(Constraints::iterator itr = _constraints.begin();
itr != _constraints.end();
++itr)
{
(*itr)-constrain(command);
}

// move self
getParentDragger()-receive(command);


for(DraggerCallbacks::iterator itr = 
getParentDragger()-getDraggerCallbacks().begin();

itr != getParentDragger()-getDraggerCallbacks().end();
++itr)
{
(*itr)-receive(command);
}
}

and we see what would be called
bool receive(const MotionCommand)

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

Re: [osg-users] What status of osgManipulator::Constraint?

2011-05-25 Thread Mikhail I. Izmestev 

Hi Robert,

25.05.2011 13:25, Robert Osfield wrote:

HI Mikhail,

So the problem is the the Rotate3DCommnd is being upcast to the base
class MotionCommand and then never the Constraint and DraggerCallbacks
only have their constrain(MotionCommand)/recive(MotionCommand)
methods called rather than the original subclass method i,e,
constain(Rotate3DCommand) and recive(Rotate3DCommand)?


Yes, it is.


If so then the problem looks to be one that would need tackling via a
double dispatch vistor pattern solution like used in
osg::Node::accept(NodeVisitor)/osg::NodeVisitor::apply(Node).  I am
on the right track?


Yes, you are right.

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

Re: [osg-users] DDS with DXT1 with and without alpha

2011-04-14 Thread Mikhail I. Izmestev 

14.04.2011 16:16, Robert Osfield wrote:


The heart of the problem is that the DDS file format doesn't
distiguish between the
two varients of DXT1, there is an alpha bit in the DDS header that
could be used,
but 3rd party tools like nvdxt and nvcompress that write DDS files
don't set this bit
so both DTX1c with black encoded pixels and DTX1a are essentially identical
in terms of header and content.


Where from this information?

$ nvdxt.exe -nomipmap -dxt1a -file test_dxt1.png -output test_dxt1a.dds
Version 8.30
Reading test_dxt1.png  [Processing] Writing .\test_dxt1a.dds

$ nvdxt.exe -nomipmap -dxt1c -file test_dxt1.png -output test_dxt1c.dds
Version 8.30
Reading test_dxt1.png  [Processing] Writing .\test_dxt1c.dds

$ md5sum.exe test_dxt1*.dds
ac1473f8822abbb2d6006de0021c6bc0 *test_dxt1a.dds
249071d0b0974593b310656acea73e1d *test_dxt1c.dds

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

Re: [osg-users] DDS with DXT1 with and without alpha

2011-04-14 Thread Mikhail I. Izmestev 

14.04.2011 16:34, Mikhail I. Izmestev wrote:

14.04.2011 16:16, Robert Osfield wrote:


The heart of the problem is that the DDS file format doesn't
distiguish between the
two varients of DXT1, there is an alpha bit in the DDS header that
could be used,
but 3rd party tools like nvdxt and nvcompress that write DDS files
don't set this bit
so both DTX1c with black encoded pixels and DTX1a are essentially
identical
in terms of header and content.


Where from this information?

$ nvdxt.exe -nomipmap -dxt1a -file test_dxt1.png -output test_dxt1a.dds
Version 8.30
Reading test_dxt1.png [Processing] Writing .\test_dxt1a.dds

$ nvdxt.exe -nomipmap -dxt1c -file test_dxt1.png -output test_dxt1c.dds
Version 8.30
Reading test_dxt1.png [Processing] Writing .\test_dxt1c.dds

$ md5sum.exe test_dxt1*.dds
ac1473f8822abbb2d6006de0021c6bc0 *test_dxt1a.dds
249071d0b0974593b310656acea73e1d *test_dxt1c.dds

Mikhail


Attach files to previous message.

Mikhail


test_dxt1a.dds
Description: Binary data


test_dxt1c.dds
Description: Binary data
attachment: test_dxt1.png___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DDS with DXT1 with and without alpha

2011-04-14 Thread Mikhail I. Izmestev 

14.04.2011 16:43, Mikhail I. Izmestev пишет:

14.04.2011 16:34, Mikhail I. Izmestev wrote:

14.04.2011 16:16, Robert Osfield wrote:


The heart of the problem is that the DDS file format doesn't
distiguish between the
two varients of DXT1, there is an alpha bit in the DDS header that
could be used,
but 3rd party tools like nvdxt and nvcompress that write DDS files
don't set this bit
so both DTX1c with black encoded pixels and DTX1a are essentially
identical
in terms of header and content.


Where from this information?

$ nvdxt.exe -nomipmap -dxt1a -file test_dxt1.png -output test_dxt1a.dds
Version 8.30
Reading test_dxt1.png [Processing] Writing .\test_dxt1a.dds

$ nvdxt.exe -nomipmap -dxt1c -file test_dxt1.png -output test_dxt1c.dds
Version 8.30
Reading test_dxt1.png [Processing] Writing .\test_dxt1c.dds

$ md5sum.exe test_dxt1*.dds
ac1473f8822abbb2d6006de0021c6bc0 *test_dxt1a.dds
249071d0b0974593b310656acea73e1d *test_dxt1c.dds

Mikhail


Attach files to previous message.

Mikhail


I'm sorry,
In DDS header really no alpha flag, my mistake :)

$ nvdxt.exe -nomipmap -alpha -dxt1a -file test_dxt1_a.png -output 
test_dxt1a_a.dds

Version 8.30
Reading test_dxt1_a.png  [Processing] Writing .\test_dxt1a_a.dds

$ nvdxt.exe -nomipmap -dxt1c -alpha -file test_dxt1_a.png -output 
test_dxt1c_a.dds

Version 8.30
Reading test_dxt1_a.png  [Processing] Writing .\test_dxt1c_a.dds

Mikhail.


test_dxt1c_a.dds
Description: Binary data
attachment: test_dxt1_a.png

test_dxt1a_a.dds
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] SubloadCallback and PBO cleanup

2011-04-01 Thread Mikhail I. Izmestev 

01.04.2011 11:41, Yurii Monakov wrote:


And everything works fine until the cleanup stage. In the code above
I've allocated a Pixel Buffer Object. Where should I place it's
deletion function (something like ext-glDeleteBuffers(1,m_pbo))? Or
I should generate/delete it on every subload call with performance
penalty?


Hi Yurii,

Instead manual generation/destructin of buffer objects use 
osg::BufferObject.


BTW using osg::BufferObject solve problems of your code with multiple 
contexts.


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

Re: [osg-users] SubloadCallback and PBO cleanup

2011-04-01 Thread Mikhail I. Izmestev 
On 04/01/11 12:02, Yurii Monakov wrote:
 Hi Mikhail,
 
 Thank you for your answer. So I should inherit from osg::BufferObject
 class and implement compileObject() method?
 

I think in your case you can try to use osg::PixelDataBufferObject as it is.

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

Re: [osg-users] OpenThreads::Mutex works differently on windows and linux

2011-03-21 Thread Mikhail I. Izmestev 
Hi Robert,

On 03/21/11 12:29, Robert Osfield wrote:
 OpenThreads::ReentrantMutex is a recursive mutex so you could use
 this, but use it sparingly as in most threaded code you shouldn't be
 re entering the same code.
Problem that 3rdparty code already use OpenThreads::Mutex, and we can't
change it to OpenThreads::ReentrantMutex.

Anyway thanks for the answer :)

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

[osg-users] OpenThreads::Mutex works differently on windows and linux

2011-03-20 Thread Mikhail I. Izmestev 
Hi *,

I discovered some strange issue, on windows normal mutex works like recursive :)
Attached test code which after compilation on linux output:
Mutex not recursive

and on windows:
Mutex is recursive

Is this feature or bug?

Mikhail.
#include OpenThreads/Mutex
#include iostream

int main()
{
	OpenThreads::Mutex m;
	m.lock();
	if(0 == m.trylock())
	{
		std::coutMutex is recursivestd::endl;
		m.unlock();
	}
	else
		std::coutMutex not recursivestd::endl;
	m.unlock();
	return 0;
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenThreads::Mutex works differently on windows and linux

2011-03-20 Thread Mikhail I. Izmestev 
20.03.2011 15:03, Mikhail I. Izmestev wrote:
 Hi *,
 
 I discovered some strange issue, on windows normal mutex works like recursive 
 :)
 Attached test code which after compilation on linux output:
 Mutex not recursive
 
 and on windows:
 Mutex is recursive
 
 Is this feature or bug?
 
 Mikhail.

Hi again,

I'm sorry about flood, I just found answer in archive [1]. But I'm in situation 
when we had
threading code coming from Windows to linux and deadlocks caused. More problems 
that windows
developers do nothing to fix it. So good solution for me is add deadlocks 
caused on windows too ;)

Mikhail.

[1] http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/14294/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Please test svn/trunk in prep for 2.9.10 dev release

2010-12-03 Thread Mikhail I. Izmestev 

03.12.2010 17:22, Robert Osfield wrote:

Hi Thomas,


I'm not sure of what form this method needs to take yet.. will do some
further thinking on the topic.

I have settled upon a new SubloadCallback method:

 class OSG_EXPORT SubloadCallback : public Referenced
 {
 public:

 virtual bool textureObjectValid(const Texture2D
texture, State  state) const
 {
 return texture.textureObjectValid(state);
 }

...

 };

And a new Texture2D helper method,
Texture2D::textureObjectValid(State) that can be used by the
SubloadCallback as above with the default implementation, or by
osg::Texture2D::apply() itself to tell whether any modifications to
the Texture2D's Image will mean that the TextureObject needs
discarding and a new one to be created.
Your latest changes caused very often call of computeInternalFormat, 
computeRequiredTextureDimensions and textureObject-match methods.
In previous code this methods called only when 
getModifiedCount(contextID) != _image-getModifiedCount().


Maybe would be better something like that:
Index: src/osg/Texture2D.cpp
===
--- src/osg/Texture2D.cpp   (revision 11982)
+++ src/osg/Texture2D.cpp   (working copy)
@@ -160,7 +160,7 @@

 // get the texture object for the current contextID.
 TextureObject* textureObject = getTextureObject(contextID);
-if (textureObject  !textureObjectValid(state))
+if (textureObject)
 {
 bool textureObjectInvalidated = false;
 if (_subloadCallback.valid())


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

Re: [osg-users] Please test svn/trunk in prep for 2.9.10 dev release

2010-12-03 Thread Mikhail I. Izmestev 
Hi,
03.12.2010 20:20, Robert Osfield wrote:
 Hi Mikhail,

 Thanks for the close observation.  I made a mistake when amending the
 code and left in the   !textureObjectValid(state) that should have
 removed.   This code was there as part of interim development that I
 decided not to follow up.

 Could you do an svn update and check again.

 Cheers,
 Robert.
Looks fine for me now.
This feature looks very useful.

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

Re: [osg-users] Compressed Sub Images

2010-11-26 Thread Mikhail I. Izmestev 

Hi,
25.11.2010 22:28, Luciano da Silva wrote:

I believe it to be something on the lines of glCompressedTexSubImage2D, 
although i don't seem to find an equivalent method in OSG's Image or Texture 
classes.

I have tried about everything i could remember, but nothing worked.

You can take a look at osg::Texture::Extensions class, method 
glCompressedTexSubImage2D.
Instance of this class you can get by static method of osg::Texture 
class getExtensions.


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

Re: [osg-users] Compressed Sub Images

2010-11-26 Thread Mikhail I. Izmestev 

Hi,
26.11.2010 17:11, Luciano da Silva wrote:

I have tried the following code:

osg::State * state = _viewer-getCamera ()-getGraphicsContext ()-getState ();

_physicalTexture-apply ( *state ); // This is the texture to be updated.

osg::Texture::Extensions * ext = osg::Texture::getExtensions ( 
state-getContextID (), true );

ext-glCompressedTexSubImage2D ( GL_TEXTURE_2D, 0, 0, 0, 128, 128, 
GL_COMPRESSED_RGBA_S3TC_DXT5_EXT, page-Tile-BufferSize, page-Tile-LoadTile () 
);

The LoadTile method returns a valid pointer to valid data. I have tested that 
previously.

This does not update the texture. It remains (aparently) unchanged in the 
render.

In your code problem maybe what you have not allocated texture object. 
Could you please show how you initialize _phisycalTexture?



I think usgin subload callback would be better in your case.

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

Re: [osg-users] texture SubloadCallback and TextureObject generating

2010-10-15 Thread Mikhail I. Izmestev 

 Hi Thomas,

15.10.2010 0:26, Thomas Hogarth wrote:

Hi Robert, Mikhail

Mikhail thanks for pointing me to this as a solution to my subload problems.

Robert, i'll take a look at the new code, but I assume this can be used to
solve my problem of not wanting the object released if the image demensions
are different to the texture dimensions?

Tom
In your case this would be a small hack. After release of texture 
object, you can reuse it using new generateTextureObject method.

For example:
code
osg::Texture::TextureObject* 
TextureSubloadCallback::generateTextureObject(const osg::Texture2D 
texture, osg::State state) const

{
  const osg::Image *image = texture.getImage();
  if(image  image-data())
  {
texture.setNumMipmapLevels(1);
int width = image-s();
int height = image-t();
texture.setTextureSize(width, height);

return osg::Texture::generateTextureObject(texture, 
state.getContextID(),GL_TEXTURE_2D,
  
texture.getNumMipmapLevels(),texture.getInternalFormat(),width,height,1,texture.getBorderWidth());

  }
  else
return 
osg::Texture2D::SubloadCallback::generateTextureObject(texture, state);

}
/code

After that in load method you can check what texture object is already 
allocated and use subload instead load.


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

Re: [osg-users] texture SubloadCallback and TextureObject generating

2010-10-14 Thread Mikhail I. Izmestev 

Hi Robert,

On 14.10.2010 17:36, Robert Osfield wrote:

I have checked these changes into svn/trunk, modified files also
attached.  Could you let me know if this works fine at your end.

Robert.

All is working very well.
Thanks Robert.

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

[osg-users] texture SubloadCallback and TextureObject generating

2010-10-06 Thread Mikhail I. Izmestev 

Hi all,

Lets see for example Texture2D. When I use SubloadCallback then 
TextureObject would be generated with empty profile:

code
void Texture2D::apply(State state) const
{
[...]
if (textureObject)
{
[...]
}
else if (_subloadCallback.valid())
{

_textureObjectBuffer[contextID] = textureObject = 
generateTextureObject(this, contextID,GL_TEXTURE_2D);


textureObject-bind();

applyTexParameters(GL_TEXTURE_2D,state);

_subloadCallback-load(*this,state);


textureObject-setAllocated(_numMipmapLevels,_internalFormat,_textureWidth,_textureHeight,1,_borderWidth);

[...]
/code
code
Texture::TextureObject* 
Texture::TextureObjectManager::generateTextureObject(const Texture* 
texture, GLenum target)

{
return generateTextureObject(texture, target, 0, 0, 0, 0, 0, 0);
}
[...]
Texture::TextureObject* Texture::generateTextureObject(const Texture* 
texture, unsigned int contextID, GLenum target)

{
return 
getTextureObjectManager(contextID)-generateTextureObject(texture, target);

}
/code

Why not to move generating TextureObject to SubloadCallback::load? It 
would be helpful to reuse already allocated TextureObjects.


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

Re: [osg-users] Texture2D subload callback gone mad

2010-10-06 Thread Mikhail I. Izmestev 
 06.10.2010 21:36, Thomas Hogarth wrote:
 What's happening is that I create a texture that is a power of two size up
 but modify with a smaller image. So then the above line detects
 the modify and says that our textureObject does not match the dimensions of
 the image and releases the texture object, which causes the subsequent load
 call.


Hi,

What you think about move texture object generation to load method of subload 
callback.
I describe this at 
http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg44322.html

This small hack would allow you to reuse previous texture object.

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

Re: [osg-users] [osgPlugins] ffmpeg plugin : big delay

2010-09-29 Thread Mikhail I. Izmestev 

Hi,


 I've tested this patch, but the delay got worst?! :?  :'

 Any idea?


Ok, can you tell me which pts of first frame?
I think you can decrease pts on first frame's pts instead 
m_stream-start_time.


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

Re: [osg-users] [osgPlugins] ffmpeg plugin : big delay

2010-09-28 Thread Mikhail I. Izmestev 
 Hi,

You can try this patch.

Mikhail.

Index: src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp
===
--- src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp(revision 11784)
+++ src/osgPlugins/ffmpeg/FFmpegDecoderVideo.cpp(working copy)
@@ -208,6 +208,7 @@
 pts = 0;
 }
 
+pts -= m_stream-start_time;
 pts *= av_q2d(m_stream-time_base);
 
 // Publish the frame if we have decoded a complete frame
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [osgPlugins] ffmpeg plugin : big delay

2010-09-28 Thread Mikhail I. Izmestev 
 Hi,

You can find patch in mailing list archive at
http://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg44088.html

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

Re: [osg-users] osgViewer::GraphicsWindowWin32 cursor issue

2010-04-21 Thread Mikhail I. Izmestev 
 Hi Mikail,

 Could you please post the whole modified file, as per the other
 requests and the detailed on the SubmissionsProtocol page.


 http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProtocol

 Thanks,
 Robert.


Hello Robert.

I don't see any reason of posting whole modified file. You can use patch:
$ cd src/osgViewer/
$ patch -p0  ~/gw.patch

For windows users patch program can be downloaded from:
http://gnuwin32.sourceforge.net/packages/patch.htm

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

Re: [osg-users] osgViewer::GraphicsWindowWin32 cursor issue

2010-04-21 Thread Mikhail I. Izmestev 
 Please provide full modified files, if you wish also provide the patch
 files as well as this sometimes can help a quick look but I don't use
 them for final merge as they just don't cut it.

Hello Robert.

I sent a patch not for final merge, just to show which part of code
causes problem.

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

Re: [osg-users] osgViewer::GraphicsWindowWin32 cursor issue

2010-03-28 Thread Mikhail I. Izmestev 
Hello.

Attached patch can solve those problems.

Mikhail.
Index: GraphicsWindowWin32.cpp
===
--- GraphicsWindowWin32.cpp (revision 11300)
+++ GraphicsWindowWin32.cpp (working copy)
@@ -2465,11 +2465,18 @@
 break;
 
 ///
-case WM_NCHITTEST :
+case WM_NCMOUSEMOVE :
+case WM_NCHITTEST   :
 ///
 {
-LONG_PTR result = _windowProcedure==0 ? ::DefWindowProc(hwnd, 
uMsg, wParam, lParam) :
-
::CallWindowProc(_windowProcedure, hwnd, uMsg, wParam, lParam);
+// WM_NCMOUSEMOVE needed because windows vista not send 
WM_NCHITTEST message correct
+// you can see that with spy++
+LONG_PTR result;
+if(uMsg == WM_NCHITTEST)
+result = _windowProcedure==0 ? ::DefWindowProc(hwnd, uMsg, 
wParam, lParam) :
+   
::CallWindowProc(_windowProcedure, hwnd, uMsg, wParam, lParam);
+else
+result = wParam;
 
 switch(result)
 {
@@ -2504,11 +2511,14 @@
break;
 
 default:
-if (_traits-useCursor  _appMouseCursor != InheritCursor)
+//we must call setCursorImpl(InheritCursor) to set back
+//_mouseCursor = InheritCursor which needed to correct 
WM_SETCURSOR handling
+if (_traits-useCursor/*  _appMouseCursor != 
InheritCursor*/)
 setCursorImpl(_appMouseCursor);
 break;
 }
-return result;
+if(uMsg == WM_NCHITTEST)
+return result;
 }
 break;
 
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgViewer::GraphicsWindowWin32 cursor issue

2010-03-26 Thread Mikhail I. Izmestev 
Hello.

I have discovered some problem using InheritCursor with
osgViewer::GraphicsWindowWin32 to make possible WM_SETCURSOR handling
in my application.

If _mouseCursor == InheritCursor then WM_SETCURSOR handler in
GraphicsWindowWin32::handleNativeWindowingEvent do nothing and
WM_SETCURSOR message sends to my application. I can set _mouseCursor
to InheritCursor by calling GraphicsWindowWin32::setCursor method, all
works fine, WM_SETCURSOR message received. But if I try to move mouse
around window border then _mouseCursor changes to another value and
never set back to InheritCursor. Problem into WM_NCHITTEST handler, it
never set _mouseCursor to InheritCursor.

Another problem with cursor into windows vista with composition
enabled. Windows vista not send WM_NCHITTEST message when mouse moved
into window caption and cursor stay as resizing. But we can use
WM_NCMOUSEMOVE message. Same problem discussed at
http://social.msdn.microsoft.com/Forums/en/windowsuidevelopment/thread/9a8a63c8-79b5-43a8-82eb-f659be947add

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

Re: [osg-users] GraphicsWindowWin32: InheritCursor problems

2009-11-12 Thread Mikhail I. Izmestev 
Mikhail I. Izmestev wrote:
 But when I try to use this solution with osg own
 window it not works, because when WM_NCHITTEST message received,
 _mouseCursor changes from InheritCursor and then WM_SETCURSOR message
 handler work incorrect.  

What you think about using _appMouseCursor instead _mouseCursor into
WM_SETCURSOR handler to solve this problem?


Index: src/osgViewer/GraphicsWindowWin32.cpp
===
--- src/osgViewer/GraphicsWindowWin32.cpp(revision 10745)
+++ src/osgViewer/GraphicsWindowWin32.cpp(working copy)
@@ -2308,11 +2308,11 @@
 ///
 case WM_SETCURSOR :
 ///
 //The cursor is only modified in response to the
WM_SETCURSOR message if the mouse cursor isn't set to
 //InheritCursor.  InheritCursor lets the user manage the
cursor externally.
-if (_mouseCursor != InheritCursor)
+if (_appMouseCursor != InheritCursor)
 {
 if (_traits-useCursor)
 ::SetCursor( _currentCursor);
 else
 ::SetCursor(NULL);

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

[osg-users] GraphicsWindowWin32: InheritCursor problems

2009-11-11 Thread Mikhail I. Izmestev 
Hello.

I need to use custom cursors. To do that I use InheritCursor, this
solution works when I use embedded window which not receive
WM_NCHITTEST message. But when I try to use this solution with osg own
window it not works, because when WM_NCHITTEST message received,
_mouseCursor changes from InheritCursor and then WM_SETCURSOR message
handler work incorrect.

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