JogAmp IRC Chat Logs

#jogamp @ irc.freenode.net - 20131029 05:05:51 (UTC)

20131029 05:05:51 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20131028050550.html
20131029 05:05:51 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20131029050551.html
20131029 05:47:55 * [Mike] (~Mike]@anon) Quit ()
20131029 07:08:42 <sgothel> @Harvey: Seems nobody missed a working Trace and Debug GL pipeline ? Regression in my commit 0002fccdcd6383874b2813dc6bbe3e33f5f00924 (fix in progress)
20131029 07:09:06 <sgothel> was returning downstream.getGL*() .. removing the debug/trace duh!
20131029 07:09:50 <sgothel> Good news .. Concurrent GL context on OSX do work - me just shall not issue another glBufferData .. right
20131029 07:10:16 <sgothel> complex use-cases/tests do have deep rabbit holes :)
20131029 07:13:39 <sgothel> .. also have to re-think volatile GLContext refs in GLAD and the native handle .. since such queries only make sense to trigger for creation, it may be OK to have them 'later' due to lack of explicit memory barrier ..
20131029 07:13:52 <sgothel> .. as long they are still there :)
20131029 07:14:45 <sgothel> hmm .. then we lock the 'to be shared' ctx anyways .. and can query the value there properly and reject it in locked state
20131029 07:28:33 * monsieur_max (~maxime@anon) has joined #jogamp
20131029 07:53:03 * xranby (~xranby@anon) Quit (Ping timeout: 260 seconds)
20131029 07:56:57 * xranby (~xranby@anon) has joined #jogamp
20131029 08:09:54 <monsieur_max> Hi there :)
20131029 08:13:01 <monsieur_max> something strange is going on when i try to play a video from a local file using glmediaplayer , on windows. Seems to be URI related stuff
20131029 08:13:11 <monsieur_max> same case under linux is working fine
20131029 08:13:24 <monsieur_max> and playing a video from internet is fine too
20131029 08:13:47 <monsieur_max> "Couldn't open URI: file:/C:/temp/test_eye.mov"
20131029 08:16:42 <monsieur_max> ( jogamp 2.1.1 )
20131029 08:28:56 <sgothel> hmm .. file://C:/ ?
20131029 08:29:58 <sgothel> file:/C:/glue .. no - should work, right
20131029 08:30:30 <sgothel> message from .. whom ? libav ?
20131029 08:32:41 <monsieur_max> sgothel: hold on, checking
20131029 08:35:48 <monsieur_max> http://pastebin.com/wcTwbyuN
20131029 08:37:37 <sgothel> yeah .. so it's from libav :(
20131029 08:37:58 <sgothel> looks like the win variant does not handle the URI notation well :(
20131029 08:38:03 <monsieur_max> is there a workaround ?
20131029 08:38:33 <sgothel> if you find one .. maybe you can help here and do your 2nd commit, i.e. URI -> local file path
20131029 08:38:44 <sgothel> how is your 1st commit going ?
20131029 08:38:51 <sgothel> oh .. breakfast .. laters (1h)
20131029 08:43:35 <monsieur_max> sgothel: errrm, it's still planned, but life can sometime suck out all the free time :P
20131029 08:44:37 <monsieur_max> it's on my todo list ( using twoodo with my team, nice tool http://www.twoodo.com/ )
20131029 09:01:10 <masterzen> sgothel: more on bug #875, the device that works are all ES2.0, the one that doesn't is ES3.0. updating bug report
20131029 09:56:01 <sgothel> @Max: Thx .. and re win-libav .. pls test to 'extract' the canonical path name (URI->File...) and if works .. offer pull req - THX
20131029 09:56:24 <sgothel> @Brice: Thx .. yes ES3 should be eligible for GL2ES2 req. .. will check
20131029 09:56:50 <sgothel> @Brice: .. and maybe the workaround .. if you find some time
20131029 10:03:16 <masterzen> sgothel: yes I entered the workaround in bug 853, just slipped a bit on the return key so it is not very well formatted but I can't edit a commit.
20131029 10:03:19 <xranby> good morning, *looking at list of items todo before 2.1.2*
20131029 10:03:34 <xranby> i have been busy the past days.. bought a house
20131029 10:03:50 <masterzen> xranby: definitely bug 875 :)
20131029 10:04:26 <sgothel> oh .. you 'made' it :) we could not find one yet we like, so postponed .. no time.
20131029 10:04:53 <masterzen> sgothel: regarding bug 875, everything seems to happen in GLContextImpl.setGLFuncAvailability that mixes gl version required with what the hardware reports, so ending up creating a king of ES3 context when requesting ES1
20131029 10:05:09 <masterzen> still suprised this still works with ES2 capable hardware
20131029 10:05:40 <masterzen> we planned an android release for today, but I think we'll revert to 2.1.0 for the moment :(
20131029 10:05:41 <sgothel> I haven't looked at it yet .. but will
20131029 10:08:06 <xranby> sgothel: do you have gles3 hardware + drivers to test on?
20131029 10:08:35 <xranby> the closest i have to gles3 is this mesa desktop drivers
20131029 10:08:40 <xranby> setup
20131029 10:09:39 <sgothel> nope .. only Mesa .. but bug doesn't trigger there .. busy w/ other bugs to finish, it's in the pipe though. Recommendations for non Sony ES3 chips are welcome :)
20131029 10:10:22 <sgothel> Yeah, the Asus Intel tablet also got delayed .. probably canceled (non avail)
20131029 10:16:06 <sgothel> @Brice: Your comment *rings a bell* .. pls check whether we allow to slip ES > 1 to become ES1, b/c we have checks only to the lower boundary ..
20131029 10:16:19 <sgothel> this works well if we have full profiles available etc .
20131029 10:16:51 <sgothel> so for ES profiles (bit flags) the major version number must match exactly .. in the verification code
20131029 10:17:03 <sgothel> maybe you can make a patch and test - then I pull
20131029 10:17:54 <sgothel> yes, it's due to relaxed version checks .. and I probably didn't consider ES3 only etc
20131029 10:21:53 <masterzen> sgothel: I'm not sure I understood what you mean. You mean we need to have strictMatch enabled instead of disabled?
20131029 10:23:05 <sgothel> i.e. we only check if hasVersion > expectedVersion
20131029 10:23:18 <sgothel> hasVersion is read via int or string method
20131029 10:23:25 <masterzen> yes, that's right
20131029 10:23:26 <sgothel> it's the validation part ..
20131029 10:23:42 <sgothel> so for ES profiles (ctxOptions) major must match 1:1
20131029 10:23:47 <masterzen> as I read it, in 2.1.0 we used what was required, in 2.1.1 we use what gl gives us.
20131029 10:24:02 <sgothel> yes
20131029 10:24:08 <sgothel> but ES3 is not ES1 :)
20131029 10:24:19 <sgothel> and they only differ by version numbers
20131029 10:24:31 <sgothel> both have same ES_.. flag
20131029 10:25:01 <sgothel> CTX_PROFILE_ES
20131029 10:25:04 <masterzen> so you mean the validation we do at the end of setGLFuncAvailable regarding the ctxProfileBits?
20131029 10:25:27 <sgothel> now I have a look :)
20131029 10:25:39 <masterzen> sorry to disturb you :)
20131029 10:25:52 <masterzen> I'm a bit lost in GLContextImpl :)
20131029 10:26:41 <sgothel> the tail ~1500 of that method only patches the option bits ..
20131029 10:26:49 <masterzen> what I see, the big diff between 2,1,0 and 2,1,1 is line 1459
20131029 10:27:15 <sgothel> Use returned GL version! <--
20131029 10:27:22 <masterzen> yes
20131029 10:27:30 <sgothel> so that is invalid .. if ES
20131029 10:27:39 <masterzen> this returns 3.0 on my sony
20131029 10:27:53 <sgothel> for ES1 .. yes
20131029 10:28:45 <masterzen> yes, but we keep that, when creating a lot of other things, like the contextFQN
20131029 10:29:01 <masterzen> so every ES1, ES2, ES3 will have the same contextFQN
20131029 10:29:09 <sgothel> if( strictMatch && major >= 3 && glIntMajor[0]<major || ( glIntMajor[0]==major && glIntMinor[0]<minor ) ) { <- needs to be strict for ES, i.e. must match major
20131029 10:29:11 <masterzen> but map to incompatible proc accr tables, no?
20131029 10:29:47 <sgothel> shall not pass those barriers .. (2 of them)
20131029 10:29:55 <sgothel> and return false
20131029 10:31:30 <sgothel> 'strictMatch && major >= 3 && glIntMajor[0]<major' -> 'strictMatch && !ES && major >= 3 && glIntMajor[0]<major'
20131029 10:32:15 <masterzen> I don't think that's enough, we'd still do the assignment to major and minor on line 1428
20131029 10:37:35 <sgothel> yeah .. so we need another || ES && hasMajor!=expMajor
20131029 10:38:18 <sgothel> and same a few lines below .. if you can make such a patch and test .. great, we can review it later than
20131029 10:39:59 <masterzen> yep, I'm going to try a patch (but jogl doesn't compile on my debian 6, grrr)
20131029 10:40:15 <sgothel> re: intel - so Android contains an emulator ?
20131029 10:40:42 <sgothel> x86 -> arm ? and that is still ok'ish perf. wise ?
20131029 10:42:40 <masterzen> sgothel: yes, google built an emulator with Intel. The perf are OK, same level as a middle-entry tablet
20131029 10:43:19 <sgothel> sure we have to add native support
20131029 10:43:28 <masterzen> definitely
20131029 10:44:00 <sgothel> however, can add this patch .. in Platform if x86 libs are n/a - you could do that as well :)
20131029 10:44:15 <monsieur_max> i'm no expert but maybe you could make a use of Genymotion, a vm system for Android.
20131029 10:44:18 <sgothel> good readability .. thx!
20131029 10:52:26 * odinsbane (~msmith@anon) has joined #jogamp
20131029 10:52:47 <odinsbane> Is there a java3d for linux that I can obtain from jogamp?
20131029 10:53:20 <sgothel> http://jogamp.org/deployment/java3d/
20131029 10:55:09 <odinsbane> great, thank you.
20131029 10:58:00 <odinsbane> What about the native files I need for that?
20131029 10:58:40 <sgothel> use JOGL
20131029 10:59:02 <sgothel> 2.1.0 should suffice .. look in forum .. Harvey's posts .. AFAIK
20131029 11:00:19 <xranby> odinsbane: http://forum.jogamp.org/Java3D-1-6-0-pre8-released-and-future-plans-tp4029680.html
20131029 11:01:20 <monsieur_max> sgothel: for your android test, x86, genymotion is supposed to be much faster than the emulator
20131029 11:02:45 <sgothel> hmm .. yeah thx, usually I try to test on the real devices 1st avoiding other sources of bugs :)
20131029 11:02:51 <sgothel> will consider
20131029 11:04:39 <monsieur_max> sgothel: ok, right way to do it. If you got any question, i'm in touch with people behind this tool
20131029 11:23:38 * odinsbane (~msmith@anon) Quit (Ping timeout: 264 seconds)
20131029 11:26:57 * xranby (~xranby@anon) Quit (Ping timeout: 272 seconds)
20131029 11:29:11 * xranby (~xranby@anon) has joined #jogamp
20131029 11:30:28 * odinsbane (~msmith@anon) has joined #jogamp
20131029 11:33:00 <odinsbane> Thanks for the help.
20131029 11:33:02 * odinsbane (~msmith@anon) Quit (Client Quit)
20131029 12:46:01 * melkor (~msmith@anon) has joined #jogamp
20131029 12:58:59 <melkor> I'm getting an error java.lang.NoClassDefFoundError: com/jogamp/opengl/FBObject.
20131029 12:59:40 <melkor> I get that error when I try to create a VirtualUniverse while running the program. It appears to be a native method.
20131029 12:59:55 <melkor> Here is the whole stack trace. http://pastie.org/8439975
20131029 13:07:36 <melkor> Okay I got it, there are quite a few version lying around and I grabed the wrong one it appears. I still get a file not found but it works, and 3D works.
20131029 13:09:26 <xranby> melkor: everything then works.. ?
20131029 13:09:40 <xranby> which file are still not found?
20131029 13:10:47 <melkor> Catched FileNotFoundException: /home/msmith/IdeaProjects/libs/jogamp-all-platforms/jar/gluegen-natives-linux-amd64.jar (No such file or directory), while addNativeJarLibsImpl(classFromJavaJar class com.jogamp.common.os.Platform, classJarURI jar:file:/home/msmith/IdeaProjects/libs/jogamp-all-platforms/jar/gluegen.jar!/com/jogamp/common/os/Platform.class, nativeJarBaseName gluegen-natives-linux-amd64.jar): [ file:/home/msmith/IdeaProjects/libs/jogamp-
20131029 13:11:04 <melkor> Sorry about that, I could only see the first part of that.
20131029 13:30:54 <xranby> melkor: do /home/msmith/IdeaProjects/libs/jogamp-all-platforms/jar/gluegen-natives-linux-amd64.jar exist?
20131029 13:31:34 <xranby> i get it you have added gluegen.jar instead of gluegen-rt.jar
20131029 13:31:57 <xranby> melkor: you can remove gluegen.jar it is not required for your usecase
20131029 13:32:06 <xranby> you only need to use gluegen-rt.jar
20131029 13:32:13 <xranby> rt == runtime
20131029 13:33:30 <melkor> ok Ill try that.
20131029 13:41:00 <melkor> That seems to work pretty well.
20131029 13:45:52 <melkor> Thanks again.
20131029 13:45:56 * melkor (~msmith@anon) Quit (Quit: out)
20131029 13:50:42 <masterzen> sgothel: I pushed a PR on github to fix 875: https://github.com/sgothel/jogl/pull/72
20131029 13:51:11 <masterzen> sgothel: it fixes the issue on our ES3 device and still allows the other to works. Tested on linux desktop too.
20131029 13:56:16 <masterzen> sgothel: not sure it's what you intended, though :)
20131029 14:54:03 * xranby (~xranby@anon) Quit (Ping timeout: 272 seconds)
20131029 14:55:26 * xranby (~xranby@anon) has joined #jogamp
20131029 15:09:28 * xranby (~xranby@anon) Quit (Remote host closed the connection)
20131029 15:12:47 <masterzen> there are some users with very strange setups: java.lang.UnsatisfiedLinkError: C:\Users\The Bubs\AppData\Local\Temp\jogamp_0000\file_cache\jln836656742605589023\jln8570784647329300255\gluegen-rt.dll: Access is denied
20131029 15:47:41 <monsieur_max> masterzen: that's my bigest fear of releasing on a scale as large as yours
20131029 15:48:00 <masterzen> yes, better be prepared for tech support...
20131029 15:48:33 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=865 <- more like this. Safari was putting the file to quarantine .. i.e. setting non-exec bit. Here (Windows) .. non readable .. non lib-loadable .. maybe virus scanner
20131029 15:48:36 <masterzen> it's incredible the variety of hardware/software combinations that doesn't work, from antiquated buggy drivers to brand new hardware you can't afford to test on :)
20131029 15:48:51 <sgothel> (since it has been written there ..)
20131029 15:50:52 <masterzen> sgothel: thanks for the pointer, interesting
20131029 15:51:39 <sgothel> https://github.com/masterzen/jogl/commit/85be81387d33224036b3fe2b02d74aab2926e028 <- IMHO it should fail (hard) .. hmm, but the if( strictMatch && !versionValidated ) {) .. later will make it so :)
20131029 15:52:26 <sgothel> will re-order a bit after merge .. still too complicated those criteria
20131029 15:53:42 <sgothel> but good we have it now .. thx, will ping you here (and bug report) to review merge and followup cleanup today or tomorrow
20131029 15:55:46 <masterzen> sgothel: ok, as I said, I'm really not sure the proposed patch is good or not. My jogl/opengl internals knowledge is very small :)
20131029 15:55:56 <masterzen> feel free to drop the patch
20131029 15:56:48 <sgothel> thx - the usual process (bugzilla/git)
20131029 16:10:02 <sgothel> dinner time .. very laters :)
20131029 16:15:53 <hharrison> masterzen: looking at your PR, you might consider changing the double-test in the if blocks
20131029 16:16:03 <hharrison> ie: if ((isES && major == hasGLVersionNumber.getMajor()) || !isES) {
20131029 16:16:06 <hharrison> becomes
20131029 16:16:39 <hharrison> if (!isES || major == hasGLVersionNumber.getMajor()) {
20131029 16:17:34 <sgothel> @Harvey: I will clean it up later a bit (the many branches, should be simplified a bit more) .. thank you!
20131029 16:17:51 <hharrison> Otherwise it seems reasonable, not that I totally understand this bit of code...but it reads well
20131029 16:18:14 <sgothel> yeah .. and that is the problem .. i.e. not 'loving it at first sight' :)
20131029 16:19:14 <sgothel> @Harvey: As I said above .. all concurrent shared ctx issues are solved .. no OSX bug. But will push changes later.
20131029 16:19:21 <hharrison> We've got a Win8 laptop in today, debugging some recursivelock timeouts
20131029 16:19:33 <sgothel> :(
20131029 16:19:50 <sgothel> but hey, great you are at it
20131029 16:20:14 <hharrison> Luckily this hasn't landed on my plate...I just get to give vague advice
20131029 16:20:29 <sgothel> JOGL deadlocks ?
20131029 16:20:45 <hharrison> Trying to tempt someone into working more closely upstream...if it ends up being a jogl bug
20131029 16:20:58 <sgothel> (haven't seen any on the Surface)
20131029 16:21:30 <sgothel> that would be great .. i.e. more contributor .. team members
20131029 16:21:38 <hharrison> resize canvas -> 5 sec timeout -> renders again
20131029 16:22:08 <sgothel> NEWT, AWT, NEWT+AWT ?
20131029 16:22:09 <hharrison> MostlyFairishRecursiveLockIMpl....or something, will let you know what we find...or smack my forehead
20131029 16:22:19 <sgothel> yup :)
20131029 16:22:34 <hharrison> JFrame with a NEWTCanvasAWT inside
20131029 16:22:37 <sgothel> yeah, we give up after 5s per default
20131029 16:23:01 <hharrison> But then it works just fine, it is only resize of the jframe/canvas that screw us
20131029 16:23:03 <sgothel> oh oh .. yes, AWT-EDT and NEWT-EDT .. and NEWT-lock .. deadly grounds
20131029 16:23:11 <hharrison> So, we'll see
20131029 16:23:15 <hharrison> :-)
20131029 16:23:28 <hharrison> It works absolutely perfectly on Win7
20131029 16:23:30 <sgothel> we have unit tests for this .. i.e. resize w/ NewtCanvasAWT ..
20131029 16:23:32 <sgothel> oh
20131029 16:23:37 <hharrison> Which is why this is such a bastard
20131029 16:23:50 <sgothel> after 2.1.2 will unpack my Win8 box
20131029 16:23:50 <hharrison> But....first win8 machine in the group....debug time!
20131029 16:24:26 <sgothel> hope it doesn't hang in some glViewport etc .. driver deadlock
20131029 16:24:49 <sgothel> analysis: use property to set-up TIMEOUT very high .. then you can stack-trace
20131029 16:24:51 <hharrison> I have my suspiciions about how it does compositing/effects in win8...but hey, who knows
20131029 16:25:15 <hharrison> you a jstack guy...of jvisualvm...other?
20131029 16:25:19 <sgothel> -Djogamp.common.utils.locks.Lock.timeout=600000 -Djogamp.debug.Lock
20131029 16:25:37 <sgothel> I use 'jstack -l' .. but sure, visualvm works as well
20131029 16:26:08 <hharrison> I actually really like later versions of visualvm. Will report back later
20131029 16:26:21 <sgothel> now I have to 'dinner' .. couldn't miss the chance w/ you :) - laters
20131029 16:35:05 * [Mike] (~Mike]@anon) has joined #jogamp
20131029 16:55:40 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20131029 17:43:22 * monsieur_max (~maxime@anon) has joined #jogamp
20131029 18:36:44 * bbbruce_ (~bx@anon) has joined #jogamp
20131029 18:42:11 <bbbruce_> hey
20131029 18:43:42 <bbbruce_> I am facing a problem with JOGL on windows7 on a machine that has two Radeon HD7870 graphics cards. Newts Window.setVisible seems to become exponentially slower when the number of displays increases
20131029 18:44:19 <bbbruce_> with 1 display I get the window instantly, with 8 displays it takes several minutes (and an mostly frozen machine) before the window is visible
20131029 18:44:28 <bbbruce_> after the window is made visible everything runs smooth and fine
20131029 18:44:55 <bbbruce_> I am using Jogl 2.1.0 (from maven)
20131029 18:45:17 <bbbruce_> is there anything I can do to fix this?
20131029 18:47:14 <monsieur_max> funnys stuff ... well, "funny"
20131029 18:48:18 <bbbruce_> also, some OpenGL code that is written in C does not have any problems opening a window
20131029 19:08:42 <rmk0> sgothel: http://mvn.io7m.com/ieee754b16
20131029 19:10:47 <rmk0> bbbruce_: have you got a test case?
20131029 19:11:13 <rmk0> sounds like something that should be in the bug tracker
20131029 19:20:01 <bbbruce_> rmk0: how should I make a test case? just a minimal NEWT based program?
20131029 19:20:09 <rmk0> yep
20131029 19:20:15 <bbbruce_> also
20131029 19:20:37 <bbbruce_> I just made two eyefinity groups. that is basically AMDs way to merge desktops into one desktop
20131029 19:21:00 <bbbruce_> so I have two desktops that are both four desktops grouped together
20131029 19:21:06 <rmk0> yow
20131029 19:21:10 <bbbruce_> I am now able to run the same program without any problems
20131029 19:21:48 <rmk0> wondering if that reduces the number of "displays" presented to JOGL
20131029 19:21:59 <bbbruce_> how would I be able to see that?
20131029 19:22:07 <rmk0> i don't know, unfortunately
20131029 19:22:11 <bbbruce_> haha
20131029 19:22:19 <rmk0> when sgothel appears, he'll most likely know more
20131029 19:23:27 <bbbruce_> ok great. Is there documentation for building jogl (including the c bits) so that I can at least poke around and attempt to fix it myself?
20131029 19:24:28 <bbbruce_> I have to run now :( but I will be back later
20131029 19:24:32 <rmk0> http://jogamp.org/jogl/doc/HowToBuild.html
20131029 19:24:36 <rmk0> see you later
20131029 21:41:02 * [Mike] (~Mike]@anon) Quit (Ping timeout: 264 seconds)
20131029 22:06:50 <hharrison> sgothel: have run into some 'fun' with GLAnimatorControl
20131029 22:07:48 <hharrison> If you implement that yourself, there is no 'stop' callback, if you close the window, it grabs your renderthread and calls Thread.stop() directly...any chance we can get a proper .stop callback added to the interface
20131029 22:23:53 <sgothel> back ..
20131029 22:24:39 <sgothel> GLAnimatorControl.stop() ? Sorry, don't understand.
20131029 22:25:37 <sgothel> GLAnimatorControl is supposed to live outside of a GLAutoDrawable/Window ..
20131029 22:26:04 <sgothel> we have implemented in a way .. that it will pause if no 'active' GLADs are attached
20131029 22:26:30 <sgothel> we also mark it a daemon thread .. so it won't hold up JVM destruction AFAIK ..
20131029 22:27:37 <sgothel> The Animator execution thread does not run as a daemon thread ..
20131029 22:27:58 <sgothel> ok .. so we keep the JVM alive .. right, a 'user base' design decision to behave similar to AWT :)
20131029 22:28:10 <hharrison> Ahh, we provided our own animator thread
20131029 22:28:25 <hharrison> And would really rather he not killed Thread.stop() called on him
20131029 22:28:50 <hharrison> GLWindow line 557
20131029 22:29:35 <hharrison> Sorry, and we would rather he not get Thread.stop() called on him
20131029 22:30:21 <hharrison> I dunno, maybe a case of 'Doctor, it hurts when I do this'
20131029 22:31:32 <sgothel> shutdownRenderingAction ?
20131029 22:31:44 <sgothel> (our lines differ a bit ..)
20131029 22:31:46 <hharrison> Yeah, it's on window close
20131029 22:32:05 <hharrison> Hmm, let me check to make sure I'm on latest master
20131029 22:32:37 <sgothel> nope .. it's on shutdown() -> JVM shutdown() :)
20131029 22:33:14 <sgothel> last chance .. since our Anim-thread is not a daemon .. and I experienced holding it up ..
20131029 22:33:49 <hharrison> Hmmm, let me do some homework before I waste any more of your time
20131029 22:33:52 <sgothel> that change also added dealing w/ ThreadDeath .. all ugly .. I know, not that I like it
20131029 22:34:29 <sgothel> but at that point .. it was more like .. allow it to exit the JVM nicely .. at all
20131029 22:34:39 <hharrison> Yeah, starting to see that
20131029 22:34:40 <sgothel> (in cases of errors .. )
20131029 22:35:03 <sgothel> should never ever really be triggered in proper apps .. :)
20131029 22:35:21 <sgothel> i.e. your anim thread should be dead by then :)
20131029 22:35:23 <hharrison> Just what are you saying about my app ;-)
20131029 22:35:43 <sgothel> You talked about my mother .. ?
20131029 22:35:45 <sgothel> :)
20131029 22:36:24 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=877 - for further Concurrency Discussion: Synchronization, Locking and Non-Blocking Access ...
20131029 22:36:41 <sgothel> last tests .. then pushing .. merging .. etc etc
20131029 22:36:52 <sgothel> (so sorry .. some git-sha1 not yet visible)
20131029 22:39:13 <hharrison> ahem, it appears I have some unterminated threads laying about
20131029 22:39:26 <hharrison> how embarrassing
20131029 22:39:50 <sgothel> yeah .. and GLWindow's shutdown hook attachment is one mitigation .. you may join the hook :)
20131029 22:41:14 <sgothel> NativeWindowFactory.addCustomShutdownHook(true /* head */, new Runnable() { ...
20131029 22:41:29 <sgothel> See .. DisplayImpl .. etc
20131029 22:43:05 <sgothel> It's funny .. when about to release next version, I always think 'thats' the best one ever' .. until .. :)
20131029 22:44:08 <hharrison> Any reason the animator threads shouldn't just be marked as daemon threads and avoid that cleanup problem?
20131029 22:44:33 <hharrison> Hey, small, continuous improvement can be a powerful thing
20131029 22:44:37 <sgothel> FYI: The issue where I thought OSX is faulty (concurrent shared ctx) was: Issued glBufferData(..) on already established VBO ..
20131029 22:44:59 <sgothel> yeah .. that 'user base decision' ..
20131029 22:45:06 <sgothel> many years ago ..
20131029 22:45:19 <sgothel> have we nailed it down .. in GLAnimControl ?
20131029 22:45:27 <sgothel> guess just in Animator :)
20131029 22:45:45 <hharrison> Yeah, this isn't jogl's problem...I'm pretty sure
20131029 22:45:49 <sgothel> so .. make your own .. or we can customize that .. if you like
20131029 22:46:13 <hharrison> We did make our own, need to track down if we are shutting down properly though...
20131029 22:47:07 * monsieur_max (~maxime@anon) has left #jogamp
20131029 23:52:07 * Schrostfutz_ (~who@anon) has joined #jogamp
20131029 23:58:10 * Schrostfutz (~who@anon) Quit (*.net *.split)
20131029 23:59:56 <sgothel> @Harvey: Pushed ..
20131030 00:00:15 <sgothel> updating bug entry 776 now ..
20131030 00:00:30 <sgothel> OSX, Linux & Windows .. all shared context tests passed
20131030 00:00:57 <rmk0> nice!
20131030 00:01:01 <sgothel> added ant target 'junit.run.sharedctx'
20131030 00:29:00 <rmk0> sgothel: not sure if you saw ieee754b16
20131030 00:29:17 <sgothel> oh .. float ?
20131030 00:29:19 <rmk0> you said to mention it if i managed to find some conversion functions, but i broke down an implemented them myself anyway
20131030 00:29:23 <rmk0> *and
20131030 00:29:46 <rmk0> it does conversion of double <-> binary16, float <-> binary16
20131030 00:29:57 <rmk0> is fully tested, seems to give the expected results for all values
20131030 00:30:10 <sgothel> great .. you mean double <-> int64 ?
20131030 00:30:21 <rmk0> no, the half-precision float format
20131030 00:30:34 <sgothel> oh
20131030 00:30:41 <rmk0> ... were we talking about two different things all along?
20131030 00:30:46 <sgothel> :)
20131030 00:30:49 <rmk0> hehe
20131030 00:31:23 <sgothel> so here comes HDR encoding I guess ?
20131030 00:31:31 <rmk0> most likely!
20131030 00:32:00 <rmk0> had some issues with colour banding on lighting... 8 bits just ain't enough
20131030 00:33:16 <sgothel> GL4 .. big-fat 64bit ? :)
20131030 00:33:30 <rmk0> hehe, one day, maybe
20131030 00:33:38 <rmk0> certainly don't have any hardware here that can do it
20131030 00:33:41 <rmk0> i'm... a bit behind the times
20131030 00:33:59 <sgothel> so no OpenCL hw ..
20131030 00:34:04 <rmk0> nope
20131030 00:34:13 <rmk0> hm, well... actually
20131030 00:34:26 <rmk0> this 4870 might have it in some form
20131030 00:35:27 <rmk0> will be buying new hardware soon
20131030 00:36:56 <rmk0> for business purposes, that is... would like to be frequently testing (if not doing outright continuous integration) on the current crop of GPUs across the three main operating systems
20131030 00:37:32 <sgothel> hmm .. maybe we can share ..
20131030 00:37:36 <rmk0> i spoke to the Xen people and apparently with the right hardware and various software features enabled, there's only about a 5% performance drop
20131030 00:37:57 <sgothel> virtual... ?
20131030 00:38:02 <rmk0> hypervisor
20131030 00:38:26 <sgothel> hmm .. you mean prep images etc .. ? jenkins Xen setup .. etc
20131030 00:38:33 <sgothel> can Xen handle ssh ?
20131030 00:38:39 <rmk0> will be something along those lines
20131030 00:38:45 <rmk0> haven't worked out all the details yet
20131030 00:38:51 <sgothel> fascinating .. if working
20131030 00:39:05 <rmk0> let's hope!
20131030 00:39:07 <sgothel> then we for sure need a full time dude for the machines :)
20131030 00:39:15 <rmk0> hehe
20131030 00:39:43 <rmk0> i think if i can cover windows 7-8 and linux on intel, amd, nvidia
20131030 00:39:51 <rmk0> and do informal testing here and there on OS X, that'll be enough
20131030 00:40:25 <rmk0> that probably means "two machines with xen, and a laptop with xen"
20131030 00:41:22 <rmk0> will obviously be including JOGL in there
20131030 00:41:24 <sgothel> yeah .. probably a PIA .. but if working etc etc .. and no sideeffects .. cool
20131030 00:41:49 <sgothel> then I like to do that as well here .. but jenkins switching Xen while 'in build' .. hmm
20131030 00:42:06 <sgothel> tried dual-boot .. but couldn't get jenkins to do the extra iteration
20131030 00:42:15 <sgothel> while dual-boot via grub worked fine
20131030 00:42:20 <rmk0> how d'you mean switching?
20131030 00:42:27 <sgothel> (remote switch .. yup)
20131030 00:42:38 <sgothel> simply do it alternately :)
20131030 00:42:46 <sgothel> win -> linux -> ..
20131030 00:42:53 <rmk0> oh... like jenkins saying "build on this host, then build on this other host", etc?
20131030 00:43:00 <sgothel> yup
20131030 00:43:07 <sgothel> since we have to satisfy the matrix ..
20131030 00:43:07 <rmk0> yeah... i gave up getting it to do that
20131030 00:43:17 <rmk0> i just wanted it to queue a job on all hosts
20131030 00:43:24 <sgothel> benefit: power savings
20131030 00:43:26 <rmk0> it would maybe manage two and then stop queuing
20131030 00:43:40 <sgothel> other than that .. none
20131030 00:43:59 <sgothel> costs of box doesn't matter compared to utility bills :)
20131030 00:44:20 <rmk0> yeah... will likely not run them 24/7
20131030 00:44:26 <rmk0> not much point them being on when i'm not awake
20131030 00:44:38 <rmk0> given that i'm the only developer here
20131030 00:44:38 <sgothel> yeah .. OSX 10.9 needs a glFLush at least .. (shared ctx)
20131030 00:44:56 <rmk0> hm
20131030 00:45:27 <rmk0> do wonder why they feel the need to write their own graphics drivers
20131030 00:45:28 <sgothel> (or a sync point .. a few more tests)
20131030 00:45:36 <sgothel> they do not ..
20131030 00:45:47 <rmk0> do they not now?
20131030 00:45:53 <sgothel> the have an abstraction layer .. which is impl. by NV/AMD/..
20131030 00:45:56 * [Mike] (~Mike]@anon) has joined #jogamp
20131030 00:46:04 <sgothel> then they have some soft impl .. like Mesa
20131030 00:46:21 <rmk0> hm... was it always this way?
20131030 00:46:24 <sgothel> at least they co-op ..
20131030 00:46:38 <sgothel> AMD did have an Apple team
20131030 00:47:09 <rmk0> well that's ... good news ... ish
20131030 00:47:09 <sgothel> yes, they hired a few of them :)
20131030 00:47:31 <rmk0> there's certainly quite a difference between apple's drivers and the drivers for XP on the same hardware
20131030 00:47:45 <rmk0> i speak from painful experience
20131030 00:48:02 <rmk0> i blame them both
20131030 00:48:49 <sgothel> oh well .. we are all just humans ..
20131030 00:49:00 <rmk0> for now!
20131030 00:49:04 <sgothel> so blobs are the problem
20131030 00:49:17 <rmk0> they are a problem
20131030 00:49:28 <rmk0> they sort of seem to be on the way out
20131030 00:52:58 <sgothel> ok .. glFInish() it shall be - or sync obj - sometimes crashed concurrent shared ctx .. on OSX 10.9 .. well, at least our code should be clean now
20131030 00:53:53 <rmk0> oh, you mentioned GLSharedContextSetter
20131030 00:54:03 <rmk0> was looking through javadoc for it and couldn't see it
20131030 00:54:09 <rmk0> i assume that's not a user-visible class
20131030 00:54:32 <sgothel> it's brand new -> git
20131030 00:54:43 <rmk0> ah, not in the release javadocs yet?
20131030 00:55:26 <rmk0> ... maybe i'm looking in the wrong place entirely
20131030 00:56:07 <sgothel> none created yet .. I just pushed
20131030 00:56:16 <rmk0> right
20131030 00:56:22 <sgothel> look at git commits
20131030 00:56:29 <rmk0> yes
20131030 00:56:57 <rmk0> i've not actually started playing with shared contexts yet, was just making sure that there actually was a utility class i'd need to be looking at when i do
20131030 00:57:14 <rmk0> will find it
20131030 00:59:36 <sgothel> ok .. closed 776
20131030 01:00:06 <sgothel> what a journey .. :)
20131030 01:00:38 <rmk0> sounded brutal
20131030 01:01:31 <sgothel> was triggered by unit test's TestSharedContextWithJTabbedPaneAWT 'usability' ..
20131030 01:01:59 <sgothel> JOGL1 vs JOGL2 .. JOGL2 does all ctor's lazy .. so needed to adapt
20131030 01:02:23 <sgothel> and when you start one thing .. ending up deep in the hole :)
20131030 01:02:29 <rmk0> yep
20131030 01:04:35 <sgothel> Bug 875 ..
20131030 01:05:26 <sgothel> but it was 'funny' that nobody missed the Debug / TRace pipeline :)
20131030 01:07:13 <rmk0> ...
20131030 01:07:19 <rmk0> missed them?
20131030 01:07:23 <rmk0> are they gone?
20131030 01:07:33 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=876
20131030 01:07:54 <sgothel> they were 'gone' .. by returning the downstream GL obj for getGL*() :)
20131030 01:08:00 <rmk0> ah!
20131030 01:08:33 <sgothel> and I was debugging shared ctx .. and .. heck .. where are the println .. :)
20131030 01:08:40 <rmk0> hehe
20131030 01:19:29 <sgothel> boolean algebra ..
20131030 01:19:40 <sgothel> simplify .. or better .. make it more readable:
20131030 01:19:44 <sgothel> if( strictMatch && !isES && major >= 3 && glIntMajor[0]<major ||
20131030 01:19:44 <sgothel> ( glIntMajor[0]==major && glIntMinor[0]<minor ) ||
20131030 01:19:44 <sgothel> ( isES && glIntMajor[0]!=major ) ) {
20131030 01:20:03 <sgothel> fail; }
20131030 01:21:02 <sgothel> readable for me .. (when relaxed :) .. but .. should be maintainable
20131030 01:31:05 <sgothel> guess I move to 'VersionNumber' types .. minor version also shall be incl . strictMatch
20131030 01:31:13 <sgothel> bogus ..
20131030 01:41:32 <sgothel> if( ( strictMatch && ( isES || major >= 3 ) && hasGLVersionByInt.compareTo(reqGLVersion) < 0 ) ||
20131030 01:41:32 <sgothel> ( isES && major != hasGLVersionByInt.getMajor() ) ) {
20131030 01:41:32 <sgothel> // fail
20131030 01:41:32 <sgothel> }
20131030 01:41:37 <sgothel> I guess that is better
20131030 01:42:40 <sgothel> // relaxed match for versions ( !isES && major < 3 ) requests, last resort!
20131030 03:50:04 * sinistersnare (~sinisters@anon) has joined #jogamp
20131030 03:55:46 <sinistersnare> hi, im trying to run jogamp (me and my newbie friend) he sent me this project that works for him
20131030 03:56:04 <sinistersnare> but im on linux so i had to add the jars. i keep getting the error defined in this file https://www.refheap.com/20278
20131030 03:58:20 <sinistersnare> actually, the error i get when i hit run is this
20131030 03:58:23 <sinistersnare> """Exception in thread "main" java.lang.NoSuchMethodError: jogamp.opengl.Debug.addTrustedPrefix(Ljava/lang/String;)V"""
20131030 03:58:31 <sinistersnare> with a random V that i dont understand
20131030 04:08:13 <sinistersnare> i checked and made sure everything in my classpath was checked just now
20131030 04:08:20 <sinistersnare> and added the JOGL folder to my source folders in eclipse
20131030 04:31:10 <sinistersnare> fixed how i was calling the script. heres the proper error https://www.refheap.com/20279
20131030 04:31:18 <sinistersnare> seems to crash on any JOGL call, but idk
20131030 05:00:06 <sinistersnare> ok
20131030 05:00:13 <sinistersnare> must be AMD/ATI drivers...
20131030 05:00:24 <sinistersnare> god damn their linux drivers! bye then...
20131030 05:00:28 * sinistersnare (~sinisters@anon) has left #jogamp
20131030 05:05:51 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20131030050551.html