<div dir="ltr">Hi Sebastian,<br><div class="gmail_extra"><br><div class="gmail_quote">On 23 October 2015 at 18:07, Sebastian Messerschmidt <span dir="ltr"><<a href="mailto:sebastian.messerschmidt@gmx.de" target="_blank">sebastian.messerschmidt@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    Thanks for the explanation. I'm still puzzled by the question which
    elements can be updated in the update-phase without setting them to
    dynamic. I always was under the impression, that the update is
    performed before cull/draw are actually executed. <br>
    Right now I need some thread safe "time slot" to change the scene
    graph in terms of inserting nodes, updating transforms etc. I guess
    it is totally okay to do this in the update callback/operation. <br>
    But for changes to images, text, an arrays of drawables I need to
    set them to DYNAMIC if I understood you correctly. So basically what
    I got is, that I could put the draw of those elements as far to
    beginning of the draw as possible. <br></div></blockquote><div><br></div><div>Have a look through the archives, I've written a lot about the DrawThreadPerContext model that I introduced back in the OSG-2.0 days.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    As for the double buffering: Can it be done at drawable level? Like
    swapping the front/back drawable back and forth, effectively
    doubling the geometry/image space needed?<br></div></blockquote><div><br></div><div>Yes, you'd do the double buffering at the StateSet and Drawable level.  Essentially you'd have Node's in the scene graph manage two alternatives and have each update, cull traversal for a frame work on one version, and draw to work on the other. You could double buffer whole subgraphs if you wanted.  <br><br>Within these double buffered StateSet and Drawable you can share all the arrays/stateattributes that are constant and just have the changing parts duplicated.<br></div><div> <br></div><div>This is advanced OSG usage though, it may well be that this added complexity isn't required at all.  You haven't really told us anything about your application usage and confirmed bottlenecks to know what is the best route for your application to get better performance.<br><br></div><div>Robert.<br></div><div><br></div></div></div></div>