JogAmp IRC Chat Logs

#jogamp @ irc.freenode.net - 20130117 17:43:42 (UTC)

[20130117 17:43:48] * CatOut (~jogamp@anon) has joined #jogamp
[20130117 17:43:48] * Topic is 'http://jogamp.org | Hacking 3D Graphics, Multimedia and Processing across Devices'
[20130117 17:43:48] * Set by rmk0 on 20130116 23:58:04
[20130117 17:43:48] -moorcock.freenode.net- [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
[20130117 17:44:52] * sgothel (~sven@anon) Quit (Quit: Leaving.)
[20130117 17:45:06] * sgothel (~sven@anon) has joined #jogamp
[20130117 17:45:06] * ChanServ sets mode +v sgothel
[20130117 18:26:13] <sgothel> (03:25:34 PM) rmk0: i want this so that i can run a test suite on each version that a given implementation supports, so that i can be sure that i'm not using, say, features that were added in 3.3 (or deprecated, etc)
[20130117 18:26:13] <sgothel> (03:29:09 PM) rmk0: i have this vague memory of sgothel saying something about each profile giving the best available context so that shared contexts can then something something something
[20130117 18:27:11] <rmk0> the something something evades me
[20130117 18:27:19] <sgothel> well - we still try to get the highest GL profile/context - but stay true w/ core/compat, i.e. we won't try to return a compat profile if GL3 is requested
[20130117 18:27:39] <sgothel> this is important to have code tested properly w/ a core context
[20130117 18:27:46] <rmk0> right
[20130117 18:27:59] <rmk0> i do only target core anywhere
[20130117 18:28:22] <sgothel> then there should be less surprises w/ ES2/ES3 :)
[20130117 18:29:41] * DemoscenePassiv (~Lutsche@anon) has joined #jogamp
[20130117 19:10:57] * gouessej (52794ea7@anon) has joined #jogamp
[20130117 19:15:17] <gouessej> hi
[20130117 19:15:33] <sgothel> Hi Julien, great you could make it
[20130117 19:15:38] <rmk0> lo
[20130117 19:15:58] <gouessej> I have used NickServ to register my nickname, I hope it will be enough this time
[20130117 19:16:17] <sgothel> yup
[20130117 19:16:43] <gouessej> I'm going to try to reproduce Runiter's bug
[20130117 19:17:18] <sgothel> what a loooong story it is, indeed .. still don't get the release-ctx issue
[20130117 19:17:21] <gouessej> I might need your help, I'm not under Windows
[20130117 19:17:50] <sgothel> sure - if you give me a little readme (repos, .. etc) I will test it
[20130117 19:18:03] <sgothel> however, the ctx release bug .. is very odd
[20130117 19:18:36] <gouessej> it is not difficult to reproduce with JoglAwtExample
[20130117 19:18:48] <sgothel> let's see if I have the prev. Ardor repos ..
[20130117 19:18:51] <gouessej> I would like to reproduce it without Ardor3D
[20130117 19:20:14] <sgothel> URL: svn://svn.code.sf.net/p/ardor3d-jogl2/code/trunk/ardor3d-jogl2
[20130117 19:20:14] <sgothel> Repository Root: svn://svn.code.sf.net/p/ardor3d-jogl2/code
[20130117 19:20:14] <sgothel> Repository UUID: 8063aef1-8031-439c-b422-348f7cea332b
[20130117 19:20:14] <sgothel> Revision: 89
[20130117 19:20:14] <sgothel> Node Kind: directory
[20130117 19:20:14] <sgothel> Schedule: normal
[20130117 19:20:14] <sgothel> Last Changed Author: gouessej
[20130117 19:20:15] <sgothel> Last Changed Rev: 89
[20130117 19:20:15] <sgothel> Last Changed Date: 2012-11-16 17:11:41 +0100 (Fri, 16 Nov 2012)
[20130117 19:20:17] <sgothel> ?
[20130117 19:20:26] <gouessej> In Eclipse, just go to File -> Import... -> GIT -> Projects from GIT and enter git://github.com/Renanse/Ardor3D
[20130117 19:20:53] <sgothel> ok.. creating new workspace ..
[20130117 19:21:00] <gouessej> unselect the ardor3d-performance module and keep the rest
[20130117 19:21:21] <gouessej> then look at JoglAwtExample in ardor3d-examples
[20130117 19:21:39] <gouessej> Of course, it is not reproducible under GNU Linux
[20130117 19:22:08] <xranby> gouessej: hi, wow amazing work you have done with jmonkeyengine3 i was surprised that all your work was in the main svn tree.
[20130117 19:22:20] <xranby> i tested it a bit last night
[20130117 19:22:34] <gouessej> Is there any lag?
[20130117 19:22:53] <sgothel> irc lag ? I cannot notice really
[20130117 19:23:20] <gouessej> No sorry, is there any slowdown when you use JMonkeyEngine 3?
[20130117 19:24:09] <xranby> gouessej: it was the first time i used it so i do not have anything to compare with
[20130117 19:24:52] <xranby> i felt the mouse movements was not responding as fast as i would expect it to
[20130117 19:24:56] <xranby> the fps was fine
[20130117 19:25:10] <xranby> but i had to sweep a lot with the move to move around in the test demos
[20130117 19:25:11] <gouessej> As soon as I (we?) fix Runiter's bug, I will prepare the demos
[20130117 19:25:26] <xranby> the keys was responsive
[20130117 19:25:30] <gouessej> JMonkeyEngine 3 doesn't use NEWT by default, you have to modify a class file to force it
[20130117 19:25:40] <xranby> so if i navigated around with wasd and the arrowkeys then it was ok
[20130117 19:25:42] <gouessej> like noxo did
[20130117 19:26:02] <xranby> i edited the preferencies file to activate the JOGL backend
[20130117 19:26:13] <xranby> and placed the jogl opt jars in libs
[20130117 19:26:48] <gouessej> you have to modify the class file containing the full name of the class called by reflection to create the display with NEWT
[20130117 19:27:13] <xranby> i have not tested that then
[20130117 19:27:26] <gouessej> I can find the exact file for you
[20130117 19:27:31] <xranby> can we create a jmonkeyengine3 thread inside the jogamp forum to speed up hacking :)
[20130117 19:28:12] <gouessej> as you wish but if we do the same thing each time I port a stuff, we'll have tons of threads...
[20130117 19:28:56] <gouessej> You have to modify JmeDesktopSystem.newContextJogl()
[20130117 19:29:14] <gouessej> case Display: ctxClazz = (Class<? extends JmeContext>) Class.forName("com.jme3.system.jogl.JoglNewtDisplay");
[20130117 19:29:26] <xranby> what i did was 1. checkout the source using svn 2. run ant 3. cd jmonkeyengine/engine/dist/ 4. java -jar jMonkeyEngine3.jar and run some demo 5. edit the prefs file .java/.userPrefs/_\!\'o\!\^@\"v\!\'4\!aw\"l\!$k\!$\!\"\&\!\'4\!~w\"p\!\'4\!~@\!g\!\$\:\!.g\!w/prefs.xml and change Renderer to <entry key="S_Renderer" value="JOGL-OpenGL2"/>
[20130117 19:29:41] <gouessej> sgothel: is everything ok?
[20130117 19:30:11] <xranby> 6. rerun the same demo using jogl
[20130117 19:30:35] <sgothel> @Julien/Xerxes: Allow me to re-advertise ECT:
[20130117 19:30:41] <sgothel> (05:44:55 PM) sgothel: @Xerxes: So ECT seems to be also very important for libGDX, jME3 .. etc ! Can give you a perf. boost .. you know it. Brice just confirmed for Omap4/Android/Kindle as well.
[20130117 19:30:41] <sgothel> (05:44:58 PM) xranby: its awesome how well these opengl es 2 centrig game engines run
[20130117 19:30:41] <sgothel> (05:45:26 PM) xranby: sgothel: do i have to do anything special to take advantage of it?
[20130117 19:30:41] <sgothel> (05:45:27 PM) sgothel: .. and also awesome how well our API plays along w/ it ..
[20130117 19:30:41] <sgothel> (05:45:42 PM) sgothel: http://jogamp.org/git/?p=jogl.git;a=commit;h=224fab1b2c71464826594740022fdcbe278867dc
[20130117 19:30:41] <sgothel> (05:45:56 PM) sgothel: http://jogamp.org/git/?p=jogl.git;a=blobdiff;f=src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/newt/TestGearsES2NEWT.java;h=3910d1881d0e8860229c9881b2a7b6091294e2bb;hp=86831a6fafe2b233ad279ce058e8d916dd6d9c6e;hb=224fab1b2c71464826594740022fdcbe278867dc;hpb=6fd9c3d84e1758ae27cd10a89237a558460ca1fb
[20130117 19:30:41] <sgothel> (05:46:22 PM) xranby: animator.setExclusiveContext(true);
[20130117 19:30:42] <sgothel> (05:46:53 PM) sgothel: yes [implying .. NEWT] - and the decoration w/ disable/enable for window lock access!
[20130117 19:30:42] <sgothel> (05:47:21 PM) sgothel: maybe best w/ disable() try { .. } finally { enable() } .. ofc
[20130117 19:31:00] <gouessej> ECT?
[20130117 19:31:02] <sgothel> @Julien: Yes .. just imported stuff .. looking at it in a minute ..
[20130117 19:31:10] <xranby> gouessej: ok i will try switch to newt and see what happend
[20130117 19:31:12] <xranby> happens
[20130117 19:31:43] <sgothel> ExclusiveContextThread (ECT) http://jogamp.org/git/?p=jogl.git;a=commit;h=224fab1b2c71464826594740022fdcbe278867dc
[20130117 19:31:57] <gouessej> Ok I remember the change list about that
[20130117 19:32:07] <sgothel> Will give you a perf. boost on certain GL impl. iff they perform poor ctx switching ..
[20130117 19:32:20] <xranby> sgothel: i can try it with libgdx
[20130117 19:32:42] <xranby> since that is what i am about to test today using a new build of jogl
[20130117 19:32:54] <sgothel> Brice and myself could see this on several GL impl. (NV Tegra2/Desktop, Omap4, ..)
[20130117 19:33:42] <xranby> 300% speed improvement sounds awesome :)
[20130117 19:34:03] <gouessej> But it will give no boost if you already manipulate the context carefully on the same thread, won't it?
[20130117 19:35:34] <gouessej> I can't use it in Ardor3D because some examples explicitly use makeCurrent() and release() on several threads
[20130117 19:35:49] <gouessej> or at least not on the thread that handles the rendering code
[20130117 19:35:59] <gouessej> I don't do that in my own code
[20130117 19:36:34] <gouessej> the public API doesn't prevent you from making the context current on any thread
[20130117 19:38:46] <gouessej> I call makeCurrent() and release() only once in TUER, it is really faster that way
[20130117 19:41:23] <sgothel> yes!
[20130117 19:41:55] <sgothel> if top API doesn't restrict it somewhat .. it won't work - right
[20130117 19:42:43] <sgothel> right now, any other non ECT display via GLAutoDrawable would be skipped, where a native makeCurrent from !ECT would starve
[20130117 19:43:57] <sgothel> so this is more a feature being called by the application - like: you know what you are doing - or if you have a simple game loop API
[20130117 19:44:30] <gouessej> I have an idea
[20130117 19:44:46] <gouessej> Is this mechanism enabled by default?
[20130117 19:45:01] <sgothel> hell no :) - would break the whole world.
[20130117 19:45:20] <sgothel> see the other link to changes to Test*GearsES2* unit test
[20130117 19:45:25] <gouessej> ok
[20130117 19:46:01] <sgothel> it also forces you to remove ECT temporary while perf. locking operation on the Window - you see it in the diff
[20130117 19:47:53] <gouessej> It completely agrees with the principle of ECT
[20130117 19:51:47] <sgothel> Ardor3D/JOGL: 2.0-b66-20121101 rc11 I guess
[20130117 19:52:03] <sgothel> so I will replace it with current stuff ?
[20130117 19:52:44] <sgothel> lets say http://jogamp.org/deployment/archive/master/gluegen_624-joal_389-jogl_896-jocl_735/
[20130117 19:53:15] <gouessej> yes
[20130117 19:53:26] <gouessej> I will update the JARs soon
[20130117 20:04:15] <gouessej> Ok I have to commit the changes
[20130117 20:12:18] <sgothel> arrgh .. Eclipse workspace setup seems to be broken - on-save .. it changes the file (trying to just fix the float/int return type change of getWheelRotation())
[20130117 20:12:44] <sgothel> prefs.editor.save_action: none
[20130117 20:13:10] <gouessej> done
[20130117 20:13:10] <sgothel> prefs.java.editor.save_action: none
[20130117 20:13:15] <gouessej> just pushed
[20130117 20:13:24] <gouessej> it's on my repo
[20130117 20:13:30] <sgothel> thx .. do you know how to disable this eclipse havoc ?
[20130117 20:13:45] <gouessej> actually, no but I can find ot
[20130117 20:13:51] <sgothel> in my local jogamp workspace .. it doesn't do 'magic' edits on save :)
[20130117 20:14:04] <sgothel> your git repo url ?
[20130117 20:14:25] <gouessej> Properties -> Java Editor -> Save Actions
[20130117 20:14:46] <gouessej> git://github.com/gouessej/Ardor3D.git
[20130117 20:14:56] <sgothel> ah .. it's in the project .. OMG :)
[20130117 20:15:00] <gouessej> I have updated the libraries and had a cast
[20130117 20:15:26] <sgothel> sweet .. so maybe Ardor3D likes to move to float as well .. otherwise .. it will miss many scroll events ..
[20130117 20:15:52] <gouessej> I will spend some time to provide a better fix
[20130117 20:17:06] <gouessej> Our competitor returns an int
[20130117 20:17:18] <gouessej> Maybe I can ask Renanse to use a float
[20130117 20:17:48] <sgothel> well, you always can do int -> float .. but not the other way around :)
[20130117 20:18:16] <sgothel> note: this is also important for e.g. Android scrolls ..
[20130117 20:18:37] <sgothel> (2 finger scroll horiz/vert)
[20130117 20:20:32] <sgothel> Catched: Context not current on current thread AWT-E... <- getting it - very good. will check whats wrong and provide a patch
[20130117 20:21:30] <gouessej> ok thanks
[20130117 20:21:36] <gouessej> Is it in my code?
[20130117 20:22:19] <sgothel> I will tell you if I know ofc :)
[20130117 20:22:45] <sgothel> for sure .. it's sort of an assumption which jogl broke w/ changes :)
[20130117 20:23:36] <gouessej> I think it was not broken that way in RC10
[20130117 20:23:51] <gouessej> but maybe I did some unsafe things on my side
[20130117 20:24:07] <sgothel> btw .. would you mind to also add the src zip files and attach them to the jar in the eclipse project (I will do this here .. just checking whether you object)
[20130117 20:24:21] <sgothel> the older source was rc10 ? ok!
[20130117 20:24:30] <sgothel> older jogl blob .. I mean
[20130117 20:27:09] <gouessej> I shouldn't have removed the 7z file
[20130117 20:27:19] <gouessej> there is a strange thing
[20130117 20:27:32] <gouessej> in JoglPbufferTextureRenderer
[20130117 20:27:40] <gouessej> the context is never released
[20130117 20:27:44] <sgothel> oh .. thats fine (too big) .. just drop jogl-java-src.zip gluegen-java-src.zip
[20130117 20:29:56] <gouessej> I'm still investigating
[20130117 20:30:27] <sgothel> me too .. I add a ThreadDump to GLContextImpl.release() .. to see where / who does it :)
[20130117 20:31:52] <sgothel> GLContextImpl line 275 - with -Djogl.debug.GLContext.TraceSwitch
[20130117 20:32:59] <gouessej> ok thanks
[20130117 20:33:33] <sgothel> but we don't need to do it in parallel I mean, I look at it now .. and tell you when done
[20130117 20:34:13] <gouessej> it's reproducible under GNU Linux :s
[20130117 20:34:16] <gouessej> no
[20130117 20:34:25] <sgothel> yes .. it is here
[20130117 20:37:39] <sgothel> AWT-EventQueue-0: GLContext.ContextSwitch: obj 0xd2f41a5, ctx 0x7fa3acb7d628, surf 0x4c0000f - release() - force: false, <197ebe66, 5006279d>[count 1, qsz 0, owner <AWT-EventQueue-0>]
[20130117 20:37:40] <sgothel> java.lang.Exception: Stack trace
[20130117 20:37:40] <sgothel> at java.lang.Thread.dumpStack(Thread.java:1249)
[20130117 20:37:40] <sgothel> at jogamp.opengl.GLContextImpl.release(GLContextImpl.java:277)
[20130117 20:37:40] <sgothel> at jogamp.opengl.GLContextImpl.release(GLContextImpl.java:272)
[20130117 20:37:40] <sgothel> at com.ardor3d.framework.jogl.JoglCanvasRenderer.releaseCurrentContext(JoglCanvasRenderer.java:110)
[20130117 20:37:40] <sgothel> at com.ardor3d.framework.jogl.JoglCanvasRenderer.draw(JoglCanvasRenderer.java:217)
[20130117 20:39:10] <gouessej> When I comment this release, it works
[20130117 20:39:16] <gouessej> but I shouldn't do that
[20130117 20:39:40] <gouessej> draw() calls makeCurrent(), does its job and then release the context
[20130117 20:39:46] <sgothel> looks like a bug in GLContext ..
[20130117 20:40:01] <sgothel> AWT-EventQueue-0: GLContext.ContextSwitch: - setCurrent() - obj 0xd2f41a5, ctx 0x7fa3acb7d628
[20130117 20:40:02] <sgothel> AWT-EventQueue-0: GLContext.ContextSwitch: obj 0xd2f41a5, ctx 0x7fa3acb7d628, surf 0x4c0000f - switch - CONTEXT_CURRENT - <197ebe66, 5006279d>[count 1, qsz 0, owner <AWT-EventQueue-0>]
[20130117 20:40:02] <sgothel> AWT-EventQueue-0: GLContext.ContextSwitch: obj 0xd2f41a5, ctx 0x7fa3acb7d628, surf 0x4c0000f - keep - CONTEXT_CURRENT - <197ebe66, 5006279d>[count 2, qsz 0, owner <AWT-EventQueue-0>]
[20130117 20:40:02] <sgothel> AWT-EventQueue-0: GLContext.ContextSwitch: obj 0xd2f41a5, ctx 0x7fa3acb7d628, surf 0x4c0000f - release() - force: false, <197ebe66, 5006279d>[count 1, qsz 0, owner <AWT-EventQueue-0>]
[20130117 20:40:16] <gouessej> yes :s
[20130117 20:40:21] <sgothel> AWT-EventQueue-0: GLContext.ContextSwitch: - setCurrent() - NULL
[20130117 20:40:21] <sgothel> AWT-EventQueue-0: GLContext.ContextSwitch: obj 0xd2f41a5, ctx 0x7fa3acb7d628, surf 0x4c0000f - switch - CONTEXT_RELEASE - <197ebe66, 5006279d>[count 0, qsz 0, owner <NULL>]
[20130117 20:40:47] <sgothel> i.e. I broke the recursive claim/release .. oops :(
[20130117 20:41:09] <gouessej> there are a very few lines involved in this aspect
[20130117 20:41:59] <gouessej> I call GLCanvas.display() only once
[20130117 20:45:13] <gouessej> sgothel: Does this bug rather come from GLDrawableHelper?
[20130117 20:45:58] <sgothel> .. which has been changed lately, maybe - the lock is decremented .. somewhere .. have to find
[20130117 20:46:31] <gouessej> invokeGLImpl()?
[20130117 20:47:14] <sgothel> it must pass through release() .. or .. an exception within makeCurrent()
[20130117 20:47:57] <sgothel> have to instrument code a bit more ..
[20130117 20:51:50] <sgothel> how can I run the demo from commandline ?
[20130117 20:52:43] <sgothel> any provided convenient script .. adding all jars to classpath ?
[20130117 20:53:20] <gouessej> no script :s
[20130117 20:53:33] <gouessej> but you can modify the one I used at LA
[20130117 20:54:24] <gouessej> I don't find it any more
[20130117 20:54:24] <sgothel> pls .. send file to me ?
[20130117 20:54:27] <sgothel> :)
[20130117 20:54:31] <sgothel> ok .. I make one
[20130117 20:57:09] <sgothel> dinner will continue later on this - will ping you for sure!
[20130117 20:57:40] <gouessej> ok enjoy yourself
[20130117 21:00:21] <xranby> gouessej: in jmonkeyengine3 both key and mouse input to the "test launcher" is broken when returning to the test launcher list after closing a window using the jogl backend. have you experienced something similar? (using AWT)
[20130117 21:00:53] <gouessej> I don't use the AWT backend and it will probably be dropped
[20130117 21:01:09] <xranby> ok, i will then patch and test using newt
[20130117 21:01:30] <gouessej> what do you mean by broken? do you have a stack trace?
[20130117 21:02:05] <xranby> the window is unresponsive.. it like the awt/swing event dispatch thread have stopped
[20130117 21:02:12] <xranby> no error reported
[20130117 21:02:54] <gouessej> oh no
[20130117 21:03:23] <gouessej> I give it a try now
[20130117 21:05:21] <xranby> steps to reproduce 1. run java -jar jMonkeyEngine3.jar 2. select class jme3test.animation.TestJaime 3. klick ok <the test runs fine> 4. close the window 5. observe that the test chooser is "frozen"
[20130117 21:06:03] <xranby> last lines seen in log
[20130117 21:06:04] <xranby> 2013-jan-17 22:04:26 com.jme3.renderer.jogl.JoglRenderer updateUniformLocation
[20130117 21:06:04] <xranby> INFO: Uniform m_NormalMap is not declared in shader [ShaderSource[name=Common/MatDefs/Shadow/PostShadow.vert, defines, type=Vertex, language=GLSL100], ShaderSource[name=Common/MatDefs/Shadow/PostShadow.frag, defines, type=Fragment, language=GLSL100]].
[20130117 21:06:04] <xranby> 2013-jan-17 22:04:29 com.jme3.system.jogl.JoglDisplay display
[20130117 21:06:04] <xranby> INFO: Display destroyed.
[20130117 21:07:56] <gouessej> I get the same thing but no freeze with NEWT
[20130117 21:07:58] <xranby> i testes svn revision 10077
[20130117 21:08:02] <gouessej> the demo works
[20130117 21:08:08] <xranby> yes the demo work
[20130117 21:08:16] <gouessej> I'm not up to date
[20130117 21:08:30] <xranby> its only the awt chooser that is stuck
[20130117 21:10:55] <gouessej> ok no freeze with NEWT, I have to try with AWT
[20130117 21:11:58] <gouessej> I reproduce your bug
[20130117 21:13:40] <gouessej> it comes from SharedResourceRunner :s
[20130117 21:18:47] <xranby> gouessej: NEWT work on my machine as well, thats good
[20130117 21:20:13] <xranby> hmm.. but the cpu now have a thread spinning after the test ended
[20130117 21:20:25] <xranby> i will check using visualvm what it is
[20130117 21:22:41] <xranby> eh..? i still got a com.jogamp.opengl.util.AWTAnimatorImpl.display() thread running with no window open
[20130117 21:26:10] <gouessej> not good
[20130117 21:26:30] <gouessej> I should look at animator.stop()
[20130117 21:33:23] <gouessej> Calling animator.stop() on the AWT EDT is not a great idea
[20130117 21:33:35] <xranby> :)
[20130117 21:34:14] <xranby> sounds impossible if the EDT is already stopped
[20130117 21:48:00] <gouessej> it doesn't happen when I comment frame.dispose()
[20130117 22:40:20] <gouessej> sgothel are you still eating? :p
[20130117 22:43:01] <sgothel> back :)
[20130117 22:44:01] <gouessej> ok :)
[20130117 22:44:24] <sgothel> oh oh .. so much to read .. errr ..
[20130117 22:45:38] <sgothel> animator.stop() .. will not block when using AWT and called from either AWT-EDT or animator thread
[20130117 22:46:32] <sgothel> or .. me cont. on the 'release' bug :)
[20130117 22:47:35] <gouessej> ok :)
[20130117 22:47:40] <gouessej> I'm still on it too
[20130117 22:51:05] <gouessej> In my humble opinion, invokeGLImpl should call makeCurrent and release only once
[20130117 22:55:40] <sgothel> thats the idea .. it just has the recursive 'option' .. i.e. if same thread already holds a different context
[20130117 22:58:09] <gouessej> invokeGLImpl has so much changed
[20130117 23:02:25] <sgothel> due to allowing ECT .. yes
[20130117 23:08:50] <gouessej> I don't see how releaseContext can be set to true
[20130117 23:10:54] <gouessej> Actually, the runnable calls makeCurrent and release
[20130117 23:11:07] <gouessej> I see ...
[20130117 23:11:34] <sgothel> recursive .. same thread .. same GLContext - should work (even though it's redundant ..)
[20130117 23:11:49] <sgothel> i.e. no need to do so .. however - it's allowed!
[20130117 23:13:01] <gouessej> When I look at the code, I don't see how it can work, invokeGLimpl calls makeCurrent and then it has to call release at the end. When the runnable calls release(), it "steals" the job of the helper
[20130117 23:13:31] <sgothel> we have a recursive lock .. only if count == 1 -> actualRelease
[20130117 23:13:43] * DemoscenePassiv (~Lutsche@anon) Quit (Ping timeout: 246 seconds)
[20130117 23:14:00] <gouessej> releaseContext = !_isExclusiveThread; -> _isExclusiveThread is set to false
[20130117 23:14:36] <sgothel> the 'actualRelease' thingy is in GLContextImpl release()
[20130117 23:14:59] <sgothel> w/ implicit counter via [recursive] lock
[20130117 23:16:13] <gouessej> ok
[20130117 23:20:43] <gouessej> it works with _joglAwtCanvas.setExclusiveContextThread(Thread.currentThread());
[20130117 23:20:55] <gouessej> in JoglInitializerRunnable
[20130117 23:21:13] <gouessej> the runnable is called from the AWT-EDT
[20130117 23:22:08] <sgothel> what I do know .. is to see the culprit via generated debug logs, i.e. who creates the imbalance - this is necessary for future debugging as well - seems like it's not good enough :(
[20130117 23:22:58] <sgothel> i.e. who is calling GLContext.release() one time too often ?
[20130117 23:24:53] <gouessej> I see what you mean
[20130117 23:25:10] <gouessej> my temporary workaround may break Ardor3D
[20130117 23:26:06] <sgothel> I will take my time too analyze this .. pls no changes in a hurry .. but will be done in 1-2 hours
[20130117 23:27:17] <gouessej> ok
[20130117 23:28:07] <gouessej> we will see which call is useless with some more logs
[20130117 23:28:18] <sgothel> yup
[20130117 23:28:28] <gouessej> I won't make a pull request now
[20130117 23:28:34] <gouessej> I need a better fix
[20130117 23:28:56] <sgothel> these type of bugs can only be catched w/ analyzing an event flow .. no static debugging
[20130117 23:29:08] <sgothel> yeah - need to understand it completly
[20130117 23:32:56] <gouessej> I'm falling asleep, good luck. I will try to investigate tomorrow morning.
[20130117 23:33:20] <sgothel> good night .. and laters, will send email .. irc log is online
[20130117 23:45:56] <gouessej> ;)
[20130117 23:46:05] * gouessej (52794ea7@anon) has left #jogamp
[20130118 00:37:06] <sgothel> culprit found - https://jogamp.org/bugzilla/show_bug.cgi?id=669
[20130118 00:37:18] <sgothel> it's in JOGL's makeCurrent()
[20130118 01:06:37] <xranby> sgothel: nice, which tool do you use for these flow analyses?
[20130118 01:06:49] <sgothel> println :)
[20130118 01:07:06] <sgothel> + brain ..
[20130118 01:07:30] <sgothel> custom instrumentation .. (if buzzwords are appropriate :)
[20130118 01:07:43] <xranby> thumbs up!
[20130118 01:07:55] <sgothel> problem is - you cannot do it in a static fashion .. well
[20130118 01:08:01] <sgothel> hence all our DEBUG stuff
[20130118 01:08:24] <sgothel> now adding unit tests .. never had any .. tsts
[20130118 01:09:33] <sgothel> so thx to Julien who triggered it .. even though it's sort of funny to call makeCurrent/release within a GLEventListener .. but those things can happen in complex scenarios - sure.
[20130118 01:14:00] <sgothel> culprit .. (damn) .. and missed boolean flag triggering lock.unlock() in finally block ..
[20130118 01:14:42] <sgothel> like: try { lala; if(sos) return; } finally { if(flag) { unlock(); } }
[20130118 01:15:07] <sgothel> after reproduction .. need to clean that code up for sure
[20130118 01:41:01] * xranby (~familjen@anon) Quit (Ping timeout: 240 seconds)
[20130118 02:40:31] <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=669 fixed
[20130118 06:42:10] * DemoscenePassiv (~Lutsche@anon) has joined #jogamp
[20130118 07:38:15] * DemoscenePassiv (~Lutsche@anon) Quit (Ping timeout: 260 seconds)
[20130118 08:52:16] * xranby (~familjen@anon) has joined #jogamp
[20130118 11:49:28] <xranby1> i quickly tested jogamp using gcj + gnu classpath and its interpreter gij. and quicly rran into this issue https://gist.github.com/7e326db34a4ed6aa7a72
[20130118 11:51:28] <xranby1> ^the above is the reduced testcase for gcj + classpath this is the exception > https://gist.github.com/4ee31b4e8e5d4282c547
[20130118 11:52:15] <xranby1> i notice that eclipse ecj actually complains when trying to compile the testcase
[20130118 11:52:40] <xranby1> ecj IntIsDirect.java
[20130118 11:52:40] <xranby1> ----------
[20130118 11:52:40] <xranby1> 1. ERROR in IntIsDirect.java (at line 12)
[20130118 11:52:40] <xranby1> if (((Buffer)i).isDirect()) {
[20130118 11:52:40] <xranby1> ^^^^^^^^
[20130118 11:52:40] <xranby1> The method isDirect() is undefined for the type Buffer
[20130118 11:52:41] <xranby1> ----------
[20130118 11:52:41] <xranby1> 2. ERROR in IntIsDirect.java (at line 31)
[20130118 11:52:42] <xranby1> if (((Buffer)intBuf).isDirect()) {
[20130118 11:52:42] <xranby1> ^^^^^^^^
[20130118 11:52:43] <xranby1> The method isDirect() is undefined for the type Buffer
[20130118 11:52:43] <xranby1> ----------
[20130118 11:53:30] <xranby1> Inside JogAmp we got this code:
[20130118 11:53:53] <xranby1> com.jogamp.common.nio.Buffers.isDirect(Buffers.java:363)
[20130118 11:54:52] <xranby1> so. is it safe to use it like we do inside gluegen or is it the gnu classpath implementation and ecj that needs fixing?
[20130118 15:04:32] <xranby1> in any case the fix for this was easy... i will send a pull request for gluegen so that we can support gcj and gij
[20130118 15:58:12] * rmk0 (~rmk0@anon) Quit (Ping timeout: 248 seconds)
[20130118 15:59:13] * rmk0 (~rmk0@anon) has joined #jogamp
[20130118 16:03:48] <xranby1> https://github.com/sgothel/gluegen/pull/13 <-- do we want to support JRE using Java 1.5 nio classpath implementation?