multithreading

If I understand things correctly, JOGL uses a single thread to do all rendering, and currently this is the AWT event queue thread (I'm still using 2.0-beta10 so this may no longer be true - I should probably upgrade...). This thread is also responsible for handling mouse and keyboard input (and all other AWT events). So the "quality"/timeliness/accuracy of these events is probably going to be easily affected by the amount of rendering you need to do. Especially if e.g. you want to know exactly when a certain key was pressed in order to perform an accurate simulation (as much as possible).

What do other people think about this?

Would it be a good idea to put GL rendering onto a separate thread, or is there a good reason why this is the same thread as AWT? And how would this be accomplished, since the setRenderingThread API has long been removed?

Thanks for any feedback & best regards!

you are basically right about AWT. I recommend reading the wiki about the different ways of doing multi-threading.
esp. the "Why using Foo for high performance is not a good idea " sections :)

start here:
http://jogamp.org/wiki/index.php/Jogl_FAQ#What_is_Newt.27s_Threading_Model_for_native_window_events_.3F

On AWT we are fairly constraind regarding MT thats right. (this area is still in development, we experiment with different locking techniques)

regards,
michael


On 06/27/2010 07:47 PM, Evert B [via jogamp] wrote:

If I understand things correctly, JOGL uses a single thread to do all rendering, and currently this is webstartthe AWT event queue thread (I'm still using 2.0-beta10 so this may no longer be true - I should probably upgrade...). This thread is also responsible for handling mouse and keyboard input (and all other AWT events). So the "quality"/timeliness/accuracy of these events is probably going to be easily affected by the amount of rendering you need to do. Especially if e.g. you want to know exactly when a certain key was pressed in order to perform an accurate simulation (as much as possible).

What do other people think about this?

Would it be a good idea to put GL rendering onto a separate thread, or is there a good reason why this is the same thread as AWT? And how would this be accomplished, since the setRenderingThread API has long been removed?

Thanks for any feedback & best regards!

---

View message @ http://jogamp.762907.n3.nabble.com/multithreading-tp925981p925981.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.

Thanks but I have a hard time understanding that stuff mainly because I have no idea what this NEWT is? I see it's name all over the place but I failed to find a clear high-level explanation about what it is and why it should be used (because it is optional right?). Sorry if I missed something obvious...

NEWT is kind of a minimal windowing toolkit. If you want to draw a OpenGL window without any controls ... this might be interesting for you.

-michael

On 06/28/2010 04:17 PM, Evert B [via jogamp] wrote:

Thanks but I have a hard time understanding that stuff mainly because I have no idea what this NEWT is? I see it's name all over the place but I failed to find a clear high-level explanation about what it is and why it should be used (because it is optional right?). Sorry if I missed something obvious...

---

View message @ http://jogamp.762907.n3.nabble.com/multithreading-tp925981p927900.html
To start a new topic under jogamp, email [hidden email]
To unsubscribe from jogamp, click here.

-- 
http://michael-bien.com/

On Thursday, July 01, 2010 23:15:57 Michael Bien [via jogamp] wrote:
>
> NEWT is kind of a minimal windowing toolkit. If you want to draw a
> OpenGL window without any controls ... this might be interesting for you.
>
> -michael

Soon a NEWT/AWT layer will be stable, allowing you to have a
native NEWT window acting as a child window of it's AWT Canvas native peer.

This 'adventurous' solution allows you to free yourself from the
AWT multithreading constraints (using awtLock, run on AWT-EDT, ..),
hence you can run your GL animation smoothly while doing other things
including AWT input.

~Sven

>
> On 06/28/2010 04:17 PM, Evert B [via jogamp] wrote:
> > Thanks but I have a hard time understanding that stuff mainly because
> > I have no idea what this NEWT is? I see it's name all over the place
> > but I failed to find a clear high-level explanation about what it is
> > and why it should be used (because it is optional right?). Sorry if I
> > missed something obvious...
> >
> > ------------------------------------------------------------------------

Is there any estimated time frame/update on when this NEWT/AWT layer will be stable?