re: NEWT Threading Overview

So currently my project uses many GLCanvas instances, but they all share a common context (I think I originally did this due to issues with textures not being shared).  Anyway I'm really interested to read about the possibilities of using NEWT & Swing together! that's really great!  So now I'm wondering how this would work in practice...

Is there a similar concept of a shared context so that the textures bound to the context are available to all the NEWT Displays (Display is the right word? or are they still called canvases - still trying to get my head around what NEWT is...)

Currently I have a base class that encapsulates my GLCanvas.  This consumes a few common keyboard and mouse events.  The owning container (dialog or frame) also attaches a listener so it also has a chance to process these same, and other events that the child wasn't interested in.  I'm wondering how a decoupled EDT will work in this case.  
is it still possible that as I switch focus between my multiple canvas's I'm going to receive my events as before?  
Does a parent container have a chance to 'add a listener' to the EDT?
I read something about 1 EDT per Display?  whereas currently swing is a single EDT for the whole app and all my canvases.  So my app currently has around 20 canvas's, does that mean now 20 EDT threads?  Does it also mean 20 rendering threads?

Anyway great to see some doku appearing for NEWT :)

PS cork=peter=brickfarmer.  I had some issues setting up my account originally

Hi!

How do you use shared contexts? I have a single GLCanvas that I move from a frame to another one but I lose the textures and the VBO :( When do you create your shared context?

I use something like this in my base class constructor.  note: I haven't ported this yet over to the very latest jogl2, so it's currently 'untested' although it has been working fine for 20+ canvases so far :)  As you can see from about 1:16 in this video:
http://www.youtube.com/watch?v=pXl3Q1r70O0
I have the main game canvas in the background and then 4 smaller canvases for building my models.

private static volatile GLContext sharedContext;
public CanvasBase(final String name, final AnimatorBase animator){
        super(caps, null, sharedContext, null);     //null for first creation
        this.name = name;
        this.animator = animator;
        glu = new GLU();
        glut = new GLUT();

        addGLEventListener(this);

        //delegate to child instances for any listeners
        setupListeners(this);

        //reset view as defined by child
        resetView();

        that = this;


        //System.out.println("CREATED: "+name+" CONTEXT: "+sharedContext);

        if (sharedContext == null) {
            sharedContext = getContext();
        }
    }

Julien, the above code might not work with the latest builds.  I've almost completed my port over to JOGL2 now, and  there is something strange going on with recursive locks in the above scenario.  Let me know if you have similar experience please.  I'm looking at the JOGL code for this, but I'm guessing the JOGL source level is 1.5? since there are custom implementations for features from the 1.6 concurrent package.  I'm still investigating, but it seems related to having a single fps animator and using 'add' / 'remove' as you switch between the multiple canvases.  I'll feedback if I find out more information.

PS this is still GLCanvas for now, ie no newt.

On Tuesday, November 30, 2010 10:47:47 Cork [via jogamp] wrote:
>
> Is there a similar concept of a shared context so that the textures bound to the context are available to all the NEWT Displays (Display is the right word? or are they still called canvases - still trying to get my head around what NEWT is...)

Dear Cork,

regarding your question I have fixed the NEWT GLWindow API adding a setter for shared GLContext,
which was missing - sorry.

http://jogamp.org/git/?p=jogl.git;a=commit;h=fd0d3f15d41d32b3987f4b88862619ef1a31b999
http://jogamp.org/git/?p=jogl.git;a=commit;h=de2a30104098216963132ed02b3dd66acd799d9e

Both include a simple shared display list example with our infamous Gears :)
Sure this would work with everything shared, hence textures as well.

This is included in build #243
http://jogamp.org/deployment/archive/master/gluegen_230-jogl_243-jocl_222/
http://jogamp.org/deployment/archive/master/gluegen_230-jogl_243-jocl_222/archive

I have cleaned up the folder structure a little bit,
so the demos are in it's own folder as well as the developer archive ZIP files (archive).

>
> Currently I have a base class that encapsulates my GLCanvas.  This consumes a few common keyboard and mouse events.  The owning container (dialog or frame) also attaches a listener so it also has a chance to process these same, and other events that the child wasn't interested in.  I'm wondering how a decoupled EDT will work in this case.  
> is it still possible that as I switch focus between my multiple canvas's I'm going to receive my events as before?  
> Does a parent container have a chance to 'add a listener' to the EDT?
NewtCanvasAWT propagates and translates all parent (Canvas) AWT events to the NEWT Window/GLWindow,
and hence to it's listener - yes.

> I read something about 1 EDT per Display?  whereas currently swing is a single EDT for the whole app and all my canvases.  So my app currently has around 20 canvas's, does that mean now 20 EDT threads?  
No.
The NEWT Display is a straight analogy to the native windowing system 'display'.
On MS Windows this just does not exist, hence it is unique.
On X11 Windowing System this is the DISPLAY connection, so when you run it all local (:0.0/null)
you deal with only unique NEWT Display as well.
To be honest, NEWT Display 'only' exists to comfort X11 and EGL.

> Does it also mean 20 rendering threads?
And here comes the beauty of NEWT,
rendering [is/threads are] decoupled from the NEWT EDT.

As mentioned in my blog (please read it, plus examples):
   http://jausoft.com/blog/2010/11/28/newt-threading-overview/

You just use as many animator threads as you wish (eg Animator)
and they are able to render independent from AWT EDT's or whatsoever.

>
> Anyway great to see some doku appearing for NEWT :)

Thanks to the request(s) - yes.

Since I am very busy with the rc2 and fixing core bugs,
it would be awesome if somebody creates a NEWT section in our wiki.
Please email me with your gpg/pgp public key id, so we can setup an account.

Cheers, Sven

>
>
>
> ______________________________________
> View message @ http://jogamp.762907.n3.nabble.com/re-NEWT-Threading-Overview-tp1991718p1991718.html
> To start a new topic under jogl, email [hidden email]
> To unsubscribe from jogl, visit
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; cell: +49 (151) 28145941
Timezone CET: PST+9, EST+6, UTC+1

On Tuesday, November 30, 2010 11:08:00 gouessej [via jogamp] wrote:
>
> Hi!
>
> How do you use shared contexts? I have a single GLCanvas that I move from a frame to another one but I lose the textures and the VBO :( When do you create your shared context?

Yes, this is a pity behavior of GLCanvas add/remove code as it is.
remove() really destroys the context, and add() creates it.

But there are good new everybody :)
In the example
  http://jogamp.org/git/?p=jogl.git;a=blob;f=src/junit/com/jogamp/test/junit/jogl/acore/TestSharedContextListAWT.java;h=b44158dce98537b7e12e4a354a702d0082f2b4ef;hb=de2a30104098216963132ed02b3dd66acd799d9e#l65
a shared drawable/context is created upfront holding the shared resources.
Using this approach your expensive GL resources are persistent.

Note: With NewtCanvasAWT the hooked GLWindow (to the AWT Canvas native peer)
is not destroyed at add/remove.

Cheers, Sven

Hi!

Thank you very much. You use a shared drawable in this example, I will try to do the same :)

The nabble email link failed for me, so anyway:

I put the newt demo stuff on hold due to the OSX issues we discussed (i only have osx to work with).  Also I need to investigate acquiring a pgp key.  Is there no way to use a single account for all these tools?  It seems like the login for the forum, bugzilla, wiki and probably git are all different?

Currently I'm investigating the issue around single fpsAnimator with multiple runtime add/remove drawable calls. I'm working with b220, is there some way with GIT to get the matching source code for b220?  or a matching zip file I can use in eclipse.   I don't see any git tags/labels for doing this.  I'm happy to investigate this myself, but I'm a total newbie with git...

The errors I see are timeouts probably due to some lock contention:

java.lang.RuntimeException: Waited 5000ms for: Thread[Timer-0,5,main] - Thread[AWT-EventQueue-0,6,main], with recursionCount 0, lock: com.jogamp.common.util.locks.RecursiveLock@7a0ec850, qsz 0
        at com.jogamp.common.util.locks.RecursiveLock.lock(RecursiveLock.java:125)
        at com.jogamp.opengl.util.AnimatorBase.remove(AnimatorBase.java:96)

On Monday, December 06, 2010 12:29:39 BrickFarmer [via jogamp] wrote:
even though I would always test with the latest, however, let's make this exercise with JOGL b220:

http://jogamp.org/deployment/archive/master/gluegen_207-jogl_220-jocl_200/jogl.artifact.properties

gluegen.build.number=207
gluegen.build.id=2010-11-17_14-03-39
gluegen.build.branch=master
gluegen.build.commit=8c6de21bc52b825788fc6290e0dbb50e6707d31c
jogl.build.number=220
jogl.build.id=2010-11-17_14-11-15
jogl.build.branch=master
jogl.build.commit=29e3b223eae9f5775d1dd34f2aaeeb3db6d9233c

this gives you the git sha1 values which you can use to pull source code,
event as a zip download on github.

You just add the sha1 to
  https://github.com/sgothel/jogl/commit/
ie:
  https://github.com/sgothel/jogl/commit/29e3b223eae9f5775d1dd34f2aaeeb3db6d9233c

then you click on 'Downloads' .. and you are good to go.

Sure, you can always reset your branch to any sha1 when using git.

We offer tags for rc's .. see v2.0-rc1.

If you like to share your bug investigation a small test case would be awesome,
then we could review and/or fix it in cooperation.

Cheers, Sven

great! I just needed to remove the ;cid... bit from the link.  

Can I assume source level is 1.5?

well you were right about not spending time on b220, it seems like the whole animation thing got rewritten in the mean time, wow! :)  I think I better wait a while for things to stabalize.

But I am still interested to know what source level you are targeting, there is a lot of scope there for making use of the concurrent package and avoiding a lot of risky manually coded threading stuff.

On Monday, December 13, 2010 21:17:28 BrickFarmer [via jogamp] wrote:
>
> well you were right about not spending time on b220, it seems like the whole animation thing got rewritten in the mean time, wow! :)  
well .. was necessary to stabilize it :)

> I think I better wait a while for things to stabalize.
the time is now ..

the webstart and webstart-next URL are already using a new RC (release candiadate),
and maybe tomorrow we publish it (will include jocl and also joal, again :)

>
> But I am still interested to know what source level you are targeting, there is a lot of scope there for making use of the concurrent package and avoiding a lot of risky manually coded threading stuff.

Well, hence our API 'equal' concurrency implementation,
feel free to give it more testing and cleanup etc - but it's already working as much I have tested.

~Sven

>> I think I better wait a while for things to stabalize.
>the time is now ..

ok, I have a bit of free time this week again :)

So using b253 I'm now investigating why I started getting "Cannot call invokeAndWait from the event dispatcher thread" from my main thread...

And same question, what source level do you target? 1.5? 1.6?

On Tuesday, December 14, 2010 10:47:40 BrickFarmer [via jogamp] wrote:
>
> >> I think I better wait a while for things to stabalize.
> >the time is now ..
>
> ok, I have a bit of free time this week again :)
>
> So using b253 I'm now investigating why I started getting "Cannot call invokeAndWait from the event dispatcher thread" from my main thread...
Opened a new email thread about this ..

>
> And same question, what source level do you target? 1.5? 1.6?
JOGL just uses 1.3 for CDC and 1.5 for desktop ..

A user may choose whatever is available, sure.

We have to reevaluate the source level when we have done our
mobile/embedded device evaluation done,
ie have our mind set what we should support.
Until then it would would be a pity to remove the 1.3 compatibility.

~Sven

Is anyone still using CDC? I thought that vanished with 1.4Vms... Android forever! :)

So the 1.3 CDC requirement currently means, for example, a 1.5 version of AnimatorBase would break compatibility? (I'm not clear on the package dependencies)

It's just that as I get more into the sources, there are more areas that I see a possibility for optimization with wait-free algorithms and synchronization free classes that 1.5 provides...

btw feel free to add me on a mailing list if this type of discussion is better offline?

On Tuesday, December 14, 2010 16:18:54 BrickFarmer [via jogamp] wrote:
>
> Is anyone still using CDC? I thought that vanished with 1.4Vms... Android forever! :)
>
> So the 1.3 CDC requirement currently means, for example, a 1.5 version of AnimatorBase would break compatibility? (I'm not clear on the package dependencies)

hell no :)

FOr example a user may implement whatever, ie GLAnimatorControl in a language level she wants,
which for sure must be compatible with 1.3 - which 1.5 is.

>
> It's just that as I get more into the sources, there are more areas that I see a possibility for optimization with wait-free algorithms and synchronization free classes that 1.5 provides...

I am curious about this, sure.
Let's discuss these things.
For sure this is not restricted to the Java level, I see these things orthogonal.
If you know a better threading sync/lock strategy for some code path
we can implement this.

Again: Jogl's implementation, ie choice of language level is not and shall not imply
any constraints for he user - the contrary should be true.
Once we lift the level to eg 1.5 all 1.3/1.4 users would be left behind,
so we have to wait until our mobile port is 'reloaded'.

>
> btw feel free to add me on a mailing list if this type of discussion is better offline?

You know my email, I guess.
However, it's ok to discuss this here as well,
giving others a chance to participate.



--
health & wealth
mailto:[hidden email] ; http://jausoft.com
land : +49 (471) 4707742 ; cell: +49 (151) 28145941
Timezone CET: PST+9, EST+6, UTC+1