Hi Carsten,
thanks for your input!
Carsten Neumann schrieb:
> Hello Christoph,
>
> Christoph Schäfer wrote:
>
>> I add some code fragments to point out whats going on. (thread a is app,
>> thread b is gui/rendering)
>>
>
> [SNIP - code]
>
> hm, I did not notice anything obvious in the above code fragments. From
> my point of view it is a little unusual that the render thread requests
> the sync, I normally think about it as having a render thread that
> produces frames as fast as possible and the app thread signalling that
> it has completed an update (a frame if you will) and the render thread
> should copy over that state to show up in the next render.
>
This is something I need to change for sure ;-)
> Anyways, I don't think that should be a problem. However, I'm wondering
> if your program remains responsive or if one if the threads just gets
> stuck in the barriers. The way I could imagine this to happen is that if
> thread A never sees the change of the m_syncForRenderingNeeded variable.
The app keeps responsive, I even can load other .osb files after the
first one and will see the correct structure of the model in the gui's
scene graph. What I've noticed right now: I can't load .wrl files
anymore. .osb will work but on loading a vrml the rendering crashes..
maybe this might be a pointer to the problem?
0-Pointer error at line 240 in
c:\ft1cs\libs\opensg2_vc80\source\system\nodecores\drawables\base\osgdrawablestatsattachmentbase.inl
(svn r1680)
OSGSystem_d.dll!OSG::DrawableStatsAttachmentBase::getValid() Zeile 240
+ 0xe Bytes C++
OSGSystem_d.dll!OSG::DrawableStatsAttachment::validate() Zeile 193 +
0x8 Bytes C++
OSGSystem_d.dll!OSG::OcclusionCullingTreeBuilder::testNode(OSG::RenderTreeNode
* pNode=0x03c8b2d8, OSG::DrawEnv & denv={...}, OSG::RenderPartitionBase
* part=0x03c342a0, float & scr_percent=0.91548216) Zeile 489 C++
OSGSystem_d.dll!OSG::OcclusionCullingTreeBuilder::testNode(OSG::RenderTreeNode
* pNode=0x03c84ce0, OSG::DrawEnv & denv={...}, OSG::RenderPartitionBase
* part=0x03c342a0, float & scr_percent=0.91548216) Zeile 542 C++
OSGSystem_d.dll!OSG::OcclusionCullingTreeBuilder::testNode(OSG::RenderTreeNode
* pNode=0x03c84960, OSG::DrawEnv & denv={...}, OSG::RenderPartitionBase
* part=0x03c342a0, float & scr_percent=0.91548216) Zeile 542 C++
OSGSystem_d.dll!OSG::OcclusionCullingTreeBuilder::draw(OSG::DrawEnv &
denv={...}, OSG::RenderPartitionBase * part=0x03c342a0) Zeile 347 C++
OSGSystem_d.dll!OSG::RenderPartition::doExecution() Zeile 453 + 0x31
Bytes C++
OSGSystem_d.dll!OSG::RenderAction::drawBuffer(unsigned int buf=0) Zeile
694 C++
OSGSystem_d.dll!OSG::RenderAction::stop(OSG::ActionBase::ResultE
res=Continue) Zeile 622 C++
OSGSystem_d.dll!OSG::Action::callStop(OSG::ActionBase::ResultE
res=Continue) Zeile 473 + 0x13 Bytes C++
OSGSystem_d.dll!OSG::Action::apply(std::_Vector_iterator<OSG::Node
*,std::allocator<OSG::Node *> > begin=0xfdfdfdfd {_sfVolume={...}
_sfTravMask={...} _sfParent={...} ...}, std::_Vector_iterator<OSG::Node
*,std::allocator<OSG::Node *> > end=0xfdfdfdfd {_sfVolume={...}
_sfTravMask={...} _sfParent={...} ...}) Zeile 293 + 0xc Bytes C++
OSGSystem_d.dll!OSG::Action::apply(OSG::Node * const node=0x03b6d9b0)
Zeile 310 + 0x43 Bytes C++
OSGSystem_d.dll!OSG::Viewport::render(OSG::RenderActionBase *
action=0x03b0df30) Zeile 402 + 0x18 Bytes C++
OSGSystem_d.dll!OSG::Window::renderAllViewports(OSG::RenderActionBase *
action=0x03b0df30) Zeile 1851 + 0x1e Bytes C++
OSGSystem_d.dll!OSG::Window::render(OSG::RenderActionBase *
action=0x03b0df30) Zeile 1806 + 0x13 Bytes C++
>
> Using a variable in this way to communicate between threads sometimes
> has strange effects. A popular (although from what I understand not 100%
> correct way) is to make the variable volatile (or at least the reads
> from it).
>
I tried it with volatile, which seems to be the better choice for
variables like this one anyway. That didn't solve the problem though.
From what I can see in the Visual Studio debugger and how the app
behaves I think the syncing is working but there is a problem with the
renderaction probably?
> Or do you have some other debug output from both threads, so that you
> know they are both running?
>
> Hope it helps,
> Carsten
>
Cheers,
Christoph
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
