Hi,
On Fri, 2005-12-02 at 11:32 +0100, Carlo Moritz Göllner wrote:
> [...]
> > > void OSG::Window::validateGLObject(UInt32 id)
> > > {
> > > [...]
> > > if(_mfGlObjectLastReinitialize[id] == 0)
> > > {
> > > obj->incRefCounter();
> > > obj->getFunctor().call(this, packIdStatus(id, initialize));
> > > ---> _mfGlObjectLastReinitialize[id] = 1; <---
> > > _lastValidate[id] = getGlObjectEventCounter();
> > > }
> > > else if [...]
> > > }
> > >
> > > The reinitialization flags are properly synchronized if I put
> > > begin/endEditCP calls around the marked line. This modification
> > > fixes my problem: no more unnecessary recreations of display-
> > > lists, no lags.
> > >
> > > Is there a reason why the write access to the field is not
> > > wrapped by begin/endEditCP calls at this place of the code?
> >
> > It's probably a bug, and we should fix it. But I'm not sure why it is a
> > problem, so I'd like to better understand what's going on.
> >
> > I could see it being a problem if the _mfGlObjectLastReinitialize field
> > was changed in your job thread, that way the old, out of date data would
> > be synchronized back into the render thread, forcing a rebuild of the
> > display lists. But given that validateGLObject is only called from the
> > render thread during rendering, the display thread should never have it
> > in its ChangeList. Unless you do begin/endEdits on the Window without
> > giving a mask, then I could see it. Do you do that? Do you know another
> > reason why that field would show up in the ChangeList?
>
> Hi Dirk,
>
> I could not find any places in my code that involve a direct modification
> of the Window by the job-thread. However, the job-thread creates new
> Geometry cores, invoking osg::Geometry::onCreate(...) as a side-effect.
> This method calls
>
> // static
> osg::Window::registerGLObject(...)
>
> to assign a GL-id to the new Geometry core. This method calls
>
> // static
> osg::Window::initRegisterGLObject(...)
>
> which calls
>
> osg::Window::doInitRegisterGLObject(...)
>
> and finally, doInitRegisterGLObject(...) edits the
> _mfGlObjectLastReinitialize field. As a consequence, this field access
> shows up in the ChangeList of the job-thread, and the out of date
> data will be applied to the aspect of the render-thread, resulting in
> a recreation of display-lists.
sorry to jump in, but we saw this class of problem once before. The
cleanest solution as of now is that the non rendering thread does not
create GLobject Id's.
There is more to it, than just seeing a recreation of display lists,
especially once the created objects should be destroyed again
potentially inside the producer thread.
Can you try the following for your job thread and see if it helps,
from a different mail :
> What I basically did is to add a way to force the loading thread not
> create any GL objects by setting
>
> FieldContainerPtr pProto = Geometry::getClassType().getPrototype();
> GeometryPtr pGeoProto = GeometryPtr::dcast(pProto);
>
> if(pGeoProto != NullFC)
> {
> pGeoProto->setIgnoreGLForAspect(OSG::Thread::getAspect());
> }
>
> pProto = TextureChunk::getClassType().getPrototype();
> TextureChunkPtr pTexChunkProto = TextureChunkPtr::dcast(pProto);
>
> if(pTexChunkProto != NullFC)
> {
> pTexChunkProto->setIgnoreGLForAspect(OSG::Thread::getAspect());
> }
>
> for this thread.
>
Note this is only available for the CVS version not for the 1.6 release,
it should be run as part of the init phase of your job thread.
Also there might be other objects around for which I did not add this
earlier like Shaders. So if you come across another container that
creates GLId's and does not have this feature let me know.
Also with this you do not have to sync back to the job thread.
As for the original problem, changes during the synchronization are
usually not recorded otherwise you would sync the changes just applied
to you rendering thread back to you job thread and back to your
rendering thread and so on.
But in general for the next version we have to put some thinking into
it as what you saw is part of a general problem which must be solved
anyway.
regards,
gerrit
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
