Renderer.updateTexture2DSubImage...

Hey

In my case, yes, the OpenGL context is current on the thread calling Scene.renderUnto with contextDropAndReclaimOnDrawEnabled set to false.

Yes, but it's a bad idea. Making the OpenGL thread current on another thread might not be supported.

Yes, rather queue your task and make the OpenGL context current just before executing your own stuff if necessary. No, no other thread is spawned, look at the source code, I don't create a thread to achieve that. When you use the queue with contextDropAndReclaimOnDrawEnabled set to true, I assume it's almost necessary to make the context current but at least you're on the right thread.

Hi,

Yeah, I did look at the code, just wanted to verify - thanks!

Tom

Hi,

Just a thought:

If all changes to Scene were handled via the GameTaskQueuing system, would this work:

renderUnto(renderer) {

  if (queue.size > 0) {
     renderer.draw(root)
     return true; // swap buffer
  }
  else {
     return false; // don't swap buffer
  }
}

As a way to not draw if nothing is changing. Many of our users work all over the place on laptops. Something for future
development. I need to get basic things working first.

Tom




}

The use of laptops is just an excuse, it can't be a valid reason to do that. Your code can work but it depends on how you use the frame handler. If Node.onDraw() is called elsewhere, it won't be enough. I'm accustomed with this kind of demand in scientific visualization, it's more a source of problems than a solution. If you really want to avoid drawing when nothing changes, draw the scene into a frame buffer object and use this FBO when there is nothing to update. This approach is much better when compositing, especially when using OpenGL in the GUI. Moreover, as you probably use AWT or Swing, some repaint is repeatedly performed anyway.

Hi,

It's an issue when there are many vertices to draw and battery power is limited. Hopefully I can experiment with your suggestion in the future.

Tom

There is no such issue in efficient "reactive" frameworks that give the illusion of continuously repainting but optimize each sub rendering task to do the costly work only when it's necessary. Repainting on demand and continuous repainting are both supported but the former is more cumbersome and error prone.

Hi,

I find that a slight delay between successive FrameHandler.updateFrame calls in the runner thread seems to help. Thanks for the reply.

Tom

I don't know what you mean. The problem is that there are several problems that aren't accurately defined and that I don't reproduce at all. If there is a delay, prove it, measure it.

You don't indicate whether the vertical synchronization is enabled.

There's confusion now. The last few posts on this thread are just related to performance. Not texture update which I can get to work by placing in the Update queue. Let me make a separate thread.