Hi Moritz,
On Thu, 2005-12-01 at 21:41 +0100, Carlo Moritz Goellner wrote:
> Hi,
>
> I've tracked down a problem of my application to a method
> called OSG::Window::validateGLObject(UInt32 id).
>
> My application uses two threads. A "job"-thread (on aspect 1)
> continuously creates new nodes and adds these nodes to the
> scenegraph.
>
> The job-thread notifies a "render"-thread (on aspect 0) about
> the changing scenegraph. The render-thread reacts and applies
> the job-thread's changelist.
>
> The render-thread will create some display-lists for the new
> nodes during the following redraw. As a side effect, the
> reinitialization flags for the GL-objects are set appropiately
> in the GlObjectLastReinitialize-field of OSG::Window.
>
> In order to sync these reinitialization flags, I apply
> the render-thread's changelist to the aspect of the job-thread
> after the redraw. However, the reinitialization flags are not
> synchronized at all and the display-lists are unnecessarily
> recreated after the next synchroncization of the job- and render-
> thread aspects. This results in serious lags.
Hm, interesting. You're the first one I know who's doing this ping-pong
synchronization. Good to know that it works. ;)
> Here is the relevant code snippet from OSGWindow.cpp. The
> suspicious line is marked by arrows.
>
> http://cvs.sourceforge.net/viewcvs.py/opensg/OpenSG/Source/System/Window/OSGWindow.cpp?rev=1.48&view=markup
>
> 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.
>
> Here is the modified code snippet:
...
>
> 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?
Thanks
Dirk
-------------------------------------------------------
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_id=7637&alloc_id=16865&op=click
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
