<div dir="ltr">Hi Sebastian,<br><div class="gmail_extra"><br><div class="gmail_quote">On 22 October 2015 at 19:54, Sebastian Messerschmidt <span dir="ltr"><<a href="mailto:sebastian.messerschmidt@gmx.de" target="_blank">sebastian.messerschmidt@gmx.de</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So basically I need to reformulate the question: Can we use the update operations to induce more parallelism?<br></blockquote><div><br></div><div>The update operation runs as part of the update traversal so is really just an alternative to update callbacks placed in the scene graph.  You could possible merge in data created by a background thread in an update operation or update callback, but this is the glue to help other background stuff work rather than creating an parallelism,<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
P.S. While your approach might not fit anyone's need, is there some code for an example which might be shared with the community? My biggest concern with OSG right now is performance, or the fact that performance loss is obfuscated.<br></blockquote><div><br></div><div>There are many different ways to optimize scene graphs for better performance, but to optimize you first need to know what the bottlenecks are.<br></div><div><br></div><div>Without knowing more specifics about the nature of your scene graph, the performance characteristics you are getting there isn't much we can do to help.  My expectation is that the performance problems aren't simply an issue of DYNAMIC/STATIC and DrawThreadPerContext usage, my expectation is that this is only an issue because other parts of the scene graph are poorly optimized.<br><br></div><div>Robert. <br></div></div></div></div>