#jogamp @ irc.freenode.net - 20150618 05:05:59 (UTC)

20150618 05:05:59 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20150617050559.html
20150618 05:05:59 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20150618050559.html
20150618 05:33:03 * jvanek (jvanek@anon) has joined #jogamp
20150618 06:39:26 * monsieur_max (~maxime@anon) has joined #jogamp
20150618 06:45:11 * elect (~elect@anon) has joined #jogamp
20150618 06:45:41 <elect> hi
20150618 07:32:08 * eclesia (~husky@anon) has joined #jogamp
20150618 07:32:14 <eclesia> good morning
20150618 07:32:21 <monsieur_max> hello
20150618 07:49:56 * sgothel (~sgothel@anon) Quit (Ping timeout: 252 seconds)
20150618 08:04:31 <elect> who is zubnix here?
20150618 08:04:38 <elect> zubzub?
20150618 08:12:59 <eclesia> has anyone try to embbed jogamp in javafx ?
20150618 08:17:17 <zubzub> I am
20150618 08:17:18 <zubzub> yes
20150618 08:17:26 <zubzub> elect: why do you ask?
20150618 08:18:50 <elect> I had this page
20150618 08:18:52 <elect> https://github.com/Zubnix/jglm/blob/master/src/main/java/com/hackoeur/jglm/Matrices.java
20150618 08:19:00 <elect> but know is no more available
20150618 08:19:05 <elect> no eclesia
20150618 08:19:47 <zubzub> ah yes I deleted it ;x
20150618 08:20:31 <zubzub> https://github.com/jroyalty/jglm/commit/4c7f3e47d1c49e3513d0c567807175525de20044
20150618 08:20:40 <zubzub> if you still want it
20150618 08:21:14 <elect> why?
20150618 08:21:27 <elect> wasnt working anymore?
20150618 08:21:38 <zubzub> I deleted it because I don't use it, and all of it's functionality (except for matrix inversion) is in the original jglm
20150618 08:22:12 <zubzub> I assumed nobody else was using it either
20150618 08:22:34 <zubzub> so if you still want it, just use the original jglm and implement that pull request (if you need matrix inversion that is)
20150618 08:24:03 <zubzub> I implemented my own matrix classes
20150618 08:24:11 <zubzub> https://github.com/Zubnix/westmalle/tree/master/wayland/src/main/java/org/westmalle/wayland/output/calc
20150618 08:24:18 <zubzub> with google auto
20150618 08:32:08 <eclesia> (have those in my project too if needed)
20150618 09:05:43 * sgothel (~sgothel@anon) has joined #jogamp
20150618 09:05:43 * ChanServ sets mode +v sgothel
20150618 09:08:24 <eclesia> sgothel: hi, quick question about javafx. (I've seen various topic about it starting ~2012 up to today) . what is the current state with javafx+jogamp ?
20150618 09:09:42 <zubzub> internal api of javafx is crap
20150618 09:09:58 <zubzub> it's also not stable enough to make a bridge between jogl & javafx
20150618 09:10:09 <eclesia> I already know, just want to know what is possible
20150618 09:10:37 <zubzub> iirc somebody on this channel made it work
20150618 09:10:56 <zubzub> and I've rephrased what that person said :p
20150618 09:11:19 <zubzub> also, javafx on windows uses directx
20150618 09:11:30 <zubzub> and that brings extra challanges
20150618 09:12:00 <eclesia> so offscreen rendering + convert to javafx image is the only way :/
20150618 09:13:55 <zubzub> there are other possibilities iirc, but on windows javafx lacks it's own needed gl libraries to make it properly work
20150618 09:14:17 <zubzub> if you add/activate those manually, then it works better
20150618 09:20:45 <xranby> oracle have no plans to Allow FX to interoperate with 3rd party (native) OpenGL visualizations https://bugs.openjdk.java.net/browse/JDK-8091324
20150618 09:21:58 <xranby> oracle have no plans to support JavaFX on ARM (Starting with 8u33, JavaFX has been removed from both Oracle JDK for ARM and Oracle Java SE Embedded.) https://www.mail-archive.com/openjfx-dev@openjdk.java.net/msg08623.html
20150618 09:24:10 <xranby> Sven/JogAmp 's detailed analysis of the situation: https://jogamp.org/bugzilla/show_bug.cgi?id=607
20150618 09:25:24 <zubzub> It's hard to express my feelings towards oracle without resorting to faul language
20150618 09:25:43 <xranby> there is some code scattered around that can do JOGL2 integration https://github.com/AqD/JOGL-FX - This repository contains a port of Spasi's LWJGL-JavaFX integration to JOGL 2:
20150618 09:27:11 <zubzub> I really hope qtjambi gets funding and/or more development
20150618 09:27:24 <zubzub> so it can support qt 5.4 instead of 4.8 now
20150618 09:27:38 <xranby> zubzub: i have been trying to convince qtjambi to use jogamp jogl 2 for quite some time
20150618 09:28:01 <zubzub> it's possible no?
20150618 09:28:03 <xranby> http://gerrit.smar.fi/#/c/285/
20150618 09:28:16 <xranby> i have a pull request on review since 2013
20150618 09:28:33 <xranby> but they insist they need compatibility with the dead jogl 1
20150618 09:28:40 <zubzub> join #qtjambi, poke them
20150618 09:28:45 <zubzub> I'll help :p
20150618 09:29:00 <xranby> zubzub: the last comments in that thread is from june 2015
20150618 09:29:06 <xranby> thus it is an active discussion
20150618 09:29:13 <xranby> the thread in the pull request
20150618 09:29:19 <xranby> feel free to add your comments
20150618 09:29:53 <zubzub> ah
20150618 09:29:53 <zubzub> ic
20150618 09:30:16 <xranby> but it looks like the diplomatic approac is to add one example for jogl2 and leave the jogl 1 example as is
20150618 09:30:25 <xranby> then they will likely merge the request
20150618 09:31:20 <zubzub> yeah I don't really understand what the issue is here
20150618 09:32:31 <zubzub> classpath collissions with jogl1 & 2?
20150618 09:33:28 <xranby> no idea
20150618 09:33:42 <xranby> if someone have code written using jogl 1 then i will continue to work
20150618 09:33:43 <eclesia> jogamp changes packages recently it should not be a problem anymore if there was one
20150618 09:34:19 <zubzub> xranby: if I as a user of qtjambi manually add jogl
20150618 09:34:27 <zubzub> I should be able to just use it?
20150618 09:34:38 <xranby> the qtjambo opengl example is selfcontained to the example code http://gerrit.smar.fi/#/c/285/7/src/java/qtjambi-examples/com/trolltech/demos/opengl/HelloGL.java
20150618 09:34:56 <xranby> it uses createExternalGLContext
20150618 09:35:08 <xranby> yes you can simply use it
20150618 09:35:35 <zubzub> ok so ok but then I don't see a point of bundling it with qtjambi?
20150618 09:35:52 <zubzub> if I have a need to use it, I can just add it to my classpath and start using it
20150618 09:36:14 <xranby> http://gerrit.smar.fi/#/c/1280/1/src/java/qtjambi-examples/com/trolltech/demos/opengl/HelloGL.java
20150618 09:36:18 <xranby> zubzub: yes
20150618 09:36:39 <xranby> zubzub: that is my point, my pull request removes the bundled jogl 1 jar and updates the example to work with jogl2
20150618 09:37:11 <zubzub> then qtjambi should remove jogl1
20150618 09:37:17 <zubzub> and add the example to their docs
20150618 09:37:19 <xranby> so in my view this should have been merged ages ago
20150618 09:37:21 <zubzub> for both jogl1 & 2
20150618 09:37:33 <zubzub> and bundle neither
20150618 09:38:44 <xranby> my patch only downloads jogl2 at build time in order for the example to compile, then it do not bundle jogl 2
20150618 09:39:23 <xranby> i see no point adding mechanics to download the jogl1 at build time because there is no upsteream jogl 1 to download from
20150618 09:39:54 <xranby> so from my point of view i dont know how to proceed with the pull request
20150618 09:41:08 <zubzub> well imho, there's no need for a pull request and jogl1 should be removed from jambi
20150618 09:41:13 <zubzub> .
20150618 09:41:18 <zubzub> the support is there
20150618 09:41:23 <zubzub> jambi can work with jogl
20150618 09:41:44 <zubzub> and an example is documentation, not build time deps
20150618 09:42:13 <zubzub> jogl1 should never have been in jambi
20150618 09:42:22 <zubzub> but I can uderstand why they did it
20150618 09:42:51 <zubzub> an example should not need to compile
20150618 09:43:09 <zubzub> unless it's part of an example project setup
20150618 09:43:16 <zubzub> which is not part of jambi itself
20150618 09:43:56 <zubzub> just my 0,02
20150618 09:49:21 <xranby> the example is part of the qt jambi demos jar
20150618 09:49:44 <zubzub> oh ok
20150618 09:50:07 <zubzub> well you can ask in the pull request what still needs to be done to get accepted
20150618 09:51:27 <xranby> qt jambis reviewers ask for: "Please ensure GL1 support continues as-is.
20150618 09:51:27 <xranby> Please create HelloGL2 as a new addition to QtJambi tree."
20150618 09:51:43 <xranby> i guess i can do that and maybe then everyone is happy
20150618 09:52:04 <xranby> although i cant see how my patch break GL1
20150618 09:52:19 <xranby> except that it changes the example how to use JOGL 1
20150618 09:52:38 <zubzub> that shouldn't be an issue imho
20150618 09:52:50 <xranby> code politics :)
20150618 09:52:59 <xranby> every happy ending needs a marrige
20150618 09:53:34 <xranby> and we need to marriage the two views of thinking
20150618 09:54:01 <xranby> then we can live happily ever after
20150618 09:55:01 <zubzub> odin_: if xranby makes those changes will you accept his pull request?
20150618 09:55:36 <zubzub> odin_: or are there other things holding it back?
20150618 10:02:11 <eclesia> xranby: marrying a dead bride ? ... yuck
20150618 10:02:37 <xranby> eclesia: life is a special case anyway
20150618 10:06:00 <elect> breathing is optional
20150618 10:19:36 <xranby> "14.37.15 < Smar> xranby: just some variable to build.properties that can be used to give the path
20150618 10:19:37 <xranby> 14.37.37 < Smar> so people who rather wants to use system stuff instead of getting some automagic downloads can do it easily
20150618 10:19:37 <xranby> 14.44.34 < Smar> xranby: oh, and maybe that downloading should be in setenv.xml?
20150618 10:19:37 <xranby> 14.44.40 < Smar> ant-contrib is handled there too"
20150618 10:19:43 <xranby> this also needs to be fixed in the build scripts
20150618 10:20:11 <xranby> and
20150618 10:20:13 <xranby> "14.49.07 < Smar> oh, and I don’t think downloading other jars but the one the build is for is wise
20150618 10:20:13 <xranby> 14.49.13 < Smar> arch can be gotten from...
20150618 10:20:13 <xranby> 14.50.18 < Smar> "qtjambi.osplatform"; // linux windows macosx
20150618 10:20:13 <xranby> 14.50.27 < Smar> "qtjambi.oscpu"; // i386 x86_64 x86 x32"
20150618 10:29:49 <odin_> the HelloGL is sample code to help another person see how to do things
20150618 10:30:04 <odin_> so it is better to have a version for jogl1 and also a version of jogl2
20150618 10:30:10 <odin_> as it helps both groups of users
20150618 10:32:24 <xranby> odin_: done http://gerrit.smar.fi/#/c/1289/1
20150618 10:32:47 <odin_> it would also be ok to put comment in jogl1 HelloGL.java sources and emit something to console to explain that jogl2 is out and better and the user might want to take a look at that instead
20150618 10:33:02 <xranby> odin: i have not yet fixed the build scipts that Smar wanted
20150618 10:33:07 <odin_> that is if you wanted/saw need to do this
20150618 10:33:30 <odin_> has Smar fixed the build logic concerning libpng yet ? I am waiting on this to respin all the linux autobuilds
20150618 10:34:35 <xranby> odin_: build scripts are delicate since the only person who can really test them is the one running the continious intergration server and build server
20150618 10:35:09 <xranby> odin_: have qtjambi added builds for 32bit ARM GNU/Linux systems?
20150618 10:35:47 <odin_> 32bit yet it builds on at least one platform, 64bit I've never had a system to build with :( the OBS autobuilders never seemed to be working for OpenSuSE
20150618 10:36:04 <odin_> s/yet/yes/
20150618 10:36:40 <xranby> do qt still treat as as a special case platform with more "compact" types?
20150618 10:36:44 <xranby> treat ARM
20150618 10:37:00 <xranby> i recall ARM headers used int instead of longs etc
20150618 10:37:16 <xranby> targeting low memory embedded systems
20150618 10:37:21 <odin_> IIRC it was RPi debian (raspbian) that was tested
20150618 10:37:40 <odin_> I think it was mainly type 'real' that was 'float' not 'double'
20150618 10:37:48 <xranby> yes that was it
20150618 10:37:54 <xranby> thank you for reminding me
20150618 10:37:56 <odin_> I don't recall any long is 32bit since that is normal for 32bit intel too!
20150618 10:40:28 <xranby> odin_: if qtjambi provides binarys that work on a raspberyr pi .. great!
20150618 10:41:24 <xranby> having at least one reference arm platform to showcase use of qtjambi is quite something
20150618 10:41:46 <xranby> especially since swing/awt performance is not good at all on most ARM platforms
20150618 10:42:09 <xranby> due to the implementation is unable to use any hardware acceleration
20150618 10:42:21 <odin_> yes the problem with debian is getting an official package/maintainer as in needed a sponsor and some commitment
20150618 10:42:50 <xranby> cant you simply poblish some jars on the qtjambi server?
20150618 10:42:52 <xranby> publish
20150618 10:42:57 <odin_> yes sure
20150618 10:43:05 <xranby> and upload a maven repository
20150618 10:43:07 <odin_> even *.deb
20150618 10:45:44 <odin_> xranby, I am waiting on Smar to fix libpng issues before anything else goes into tree, so i keep pushing him on that
20150618 10:47:13 * doev (~doev@anon) has joined #jogamp
20150618 10:47:22 <xranby> odin_: thank you for your support
20150618 11:03:37 <eclesia> api design question : do you think a Texture (GL) should implement the Image interface ?
20150618 11:05:26 <xranby> eclesia: do the API sifferentiate between on GPU memory and on CPU memory?
20150618 11:06:01 <xranby> the API should be designed to avoid over CPU copys
20150618 11:07:02 <eclesia> xranby: think a bit larger. Image api are used by image reader and writers so they are on cpu
20150618 11:10:09 <xranby> eclesia: what is the difference between an Image on the CPU and a Texture (GL) on the CPU ?
20150618 11:11:07 <eclesia> xranby: currently the Texture has a getImage method.
20150618 11:11:47 <xranby> can all code that today uses a Texture use an Image?
20150618 11:12:23 <eclesia> outside opengl everthing works with Image
20150618 11:13:22 <eclesia> my objective is to split out opengl from the 3d model loaders
20150618 11:13:43 <eclesia> now, those loaders create TExture objects and put them in meshes
20150618 11:14:18 <eclesia> so I need to replace texture by something else --> image
20150618 11:14:30 <eclesia> I'm just wondering if it's a good idea
20150618 11:15:19 <xranby> IMHO, as long as you are on the CPU you should use the image
20150618 11:16:03 <xranby> and if you upload the model + images to the PGU using OpenGL then you should have objects with references to the GPU memory
20150618 11:16:15 <eclesia> sure, but my question is should : Texture implements Image ?
20150618 11:16:49 <xranby> what you have describes up to now is that Texture and Image are two classes that basically contain the same information, thus you should drop one
20150618 11:17:19 <xranby> and have your entire API use Image including the model loaders
20150618 11:17:32 <eclesia> Texture is specific to opengl, it has method to upload/download from the gpu memory
20150618 11:17:51 <eclesia> so at least Texture should be a subtype of image
20150618 11:18:05 <eclesia> an 'optimzed' type
20150618 11:18:08 <eclesia> optimized*
20150618 11:19:18 <xranby> do you have a class that represent a Texture on the GPU?
20150618 11:22:40 <xranby> eclesia: I do not think I have experience enough to give you good input on the API design here. I hope someone else can elaborate if it is best to subclass Texture to implement Image or if it is better to have Images and some class that can use images to produce a new class that represent textures on the GPU
20150618 11:23:46 <sgothel> a PixelRectangle could be a feasible abstraction (we have one in nativewindow package for color-space transformations)
20150618 11:24:33 <sgothel> then JOGL has some memory ownership interface to deal w/ pixel buffer, but no OO derivation to plain old Texture class
20150618 11:24:41 <sgothel> from scratch ?
20150618 11:25:05 <sgothel> I would accompany both .. i.e. TextureRectangle and the memory ownership - then specialize for GL
20150618 11:25:23 <eclesia> from scratch ^^ I already have everything working, it's just a design question
20150618 11:25:33 <sgothel> the latter would imply an implementation for data-type and pixel color - and - memory transfer/ownership
20150618 11:26:04 <sgothel> just brainstorming - 'from scratch': i.e. vanilla design w/o preexisting API
20150618 11:27:26 <sgothel> so 'javafx' is dead officially I assume - i.e. no more support for ARM/embedded, as Xerxes pointed out. Well, Oracle is in a 'soul searching' mode now anyways it seems (stock market .. revenue .. there was some report)
20150618 11:28:14 <zubzub> javafx is dead for arm
20150618 11:28:16 <zubzub> but hey
20150618 11:28:19 * jvanek (jvanek@anon) Quit (Quit: Leaving)
20150618 11:28:22 <zubzub> you can still use openjfx
20150618 11:28:41 <zubzub> teh communaitie!1! ~Oracle
20150618 11:29:15 <zubzub> they did pretty much what I feared would happen when they took over sun
20150618 11:30:51 <xranby> projects have picked up the message well and started to migrate to opengl frameworks "First @java opengl test withtout JavaFX on the @Raspberry_Pi " https://twitter.com/Pi_Dome/status/560212534662561792/photo/1
20150618 11:34:52 <xranby> sgothel: thank you for the raspberry pi dispmanx mousepointer implementation, i will code review it and try figure out why the overlay do not line up with the dispmanx glwindow
20150618 11:35:48 <xranby> most likely something simple, i find enjoyment having something you can solve while reading the code
20150618 11:38:59 <xranby> meanwhile, when anholts new opengl driver with full X11 support is working then we do not need to use the dispmanx implementation
20150618 11:40:19 <xranby> zubzub: good news is that the arm jdk/jre will be reduced in footprint for each oracle release
20150618 12:01:19 <xranby> if someone wants to use OpenJFX in combination with Oracles binary JDk then they have to fork OpenJFX and patch it to stay licence compatible https://www.raspberrypi.org/forums/viewtopic.php?f=81&t=97367&p=776453#p776453
20150618 12:02:36 <xranby> so yes it is deat
20150618 12:02:39 <xranby> dead
20150618 12:02:46 <xranby> its even licence incompatible
20150618 12:04:33 <zubzub> does openjdk have good arm jit?
20150618 12:04:43 <zubzub> oracle sure made mess
20150618 12:05:02 <xranby> zubzub: the openjdk arm jit is about half the speed of the oracle jit
20150618 12:05:06 <sgothel> AFAIK the arm64(bit) will have one?
20150618 12:05:14 <sgothel> (a good one .. ?)
20150618 12:05:14 <xranby> arm64 will have a proper fast jit
20150618 12:05:21 <zubzub> 11:25 < zubzub> It's hard to express my feelings towards oracle without resorting to faul language
20150618 12:05:42 <zubzub> only the 64bit? :/
20150618 12:05:52 <sgothel> http://www.theregister.co.uk/2015/06/17/oracle_q4_2015_results_database_cloud/ <- seems like they have other issues at the moment
20150618 12:06:35 <xranby> zubzub: arm64 is a new architecture and redhat in combination with linaro have contributed a full AARCH64 hotspot JIT with both client C1 and server C2
20150618 12:06:40 <xranby> that is actively working on
20150618 12:07:22 <zubzub> oh well it's something
20150618 12:07:30 <zubzub> I'm still waiting for icedtea 3 :p
20150618 12:07:47 <zubzub> so I can contribute a wayland backend to javafx
20150618 12:08:01 <zubzub> I don't want to sign my rights away to oracle
20150618 12:08:09 <xranby> zubzub: ah.. icedtea 3 is buildable froun source, and debian sid/testing have binarys released
20150618 12:08:40 <xranby> debian also build openjfx pacakges
20150618 12:08:43 <zubzub> that oracle ceo looks like that guy from the office (US version)
20150618 12:08:51 <xranby> thus you may send them a patch.. or send the patch to the icedtea mailinglist
20150618 12:09:10 <xranby> where we can host patches from contributors that prefer not to sign the OCA
20150618 12:09:45 <xranby> the whole arm32 jit is only available when using the icedtea sources
20150618 12:10:18 <xranby> if you use the code in openjdk then you will have a jit that is three times slower compared to the icedtea openjdk version
20150618 12:10:45 <zubzub> ah the icedtea version has a descent jit for arm?
20150618 12:10:48 <xranby> i am a living historical lexicon on the subject
20150618 12:10:50 <zubzub> that's good to hear
20150618 12:10:58 <zubzub> I assumed both icedtea and openjdk had the same arm jit
20150618 12:13:24 <zubzub> I secretly wish for a good java ecosystem for embedded devices
20150618 12:13:24 <xranby> the icedtea jit includes edward nevills micro jit http://openjdk.linaro.org/arm32jit/fosdem15.pdf
20150618 12:13:34 <zubzub> one that is not android
20150618 12:14:16 <xranby> http://community.arm.com/groups/internet-of-things/blog/2010/04/15/how-do-you-make-java-fast-answer-go-down-the-pub
20150618 12:14:21 <xranby> http://community.arm.com/groups/internet-of-things/blog/2010/05/06/how-do-you-make-java-fast-answer-go-down-the-pub-part-2
20150618 12:15:02 <xranby> these two post covers the work sponsored by ARM, implemented by Edward Nevill to speed up icedtea on 32bit arm
20150618 14:33:43 <xranby> hmm.. did we recently bump to compile for openjdk 7 + ?
20150618 14:35:00 <xranby> i have a system that is using openjdk-6 that failed to find the jogamp.openal.AlImpl class
20150618 14:36:43 <zubzub> no idea
20150618 14:36:44 <zubzub> ask sgothel
20150618 14:46:40 * xranby is recompiling joal using openjdk-6
20150618 14:51:47 <xranby> (openjdk-7) is not packaged for debian squeeze that this production machine is running
20150618 15:01:45 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150618 15:22:29 * doev (~doev@anon) Quit (Ping timeout: 246 seconds)
20150618 15:38:14 * jvanek (jvanek@anon) has joined #jogamp
20150618 15:46:32 * elect (~elect@anon) Quit (Ping timeout: 272 seconds)
20150618 15:52:18 <sgothel> ../build-x86_64/classes/jogamp/openal/ALImpl.class
20150618 16:01:16 * eclesia (~husky@anon) has left #jogamp
20150618 16:07:20 <xranby> sgothel: its possible the error was a bug in an old version of netx (webstart)
20150618 16:07:44 <xranby> sgothel: the system manages to find ALImpl now
20150618 16:32:05 <xranby> hurray, i am happy, it is working, i have joal playing audio on a small usb screenw ith built in audio device now on this old production system
20150618 16:34:34 <xranby> if someone fail to initialize joal using a system with usb audio with the following error: alsalib cannot find card 0 then you need to edit /etc/modprobe.d/alsa-base.conf and remove the line
20150618 16:34:35 <xranby> # Keep snd-usb-audio from beeing loaded as first soundcard
20150618 16:34:36 <xranby> options snd-usb-audio index=-2
20150618 16:35:00 <xranby> took me ages to understand that :)
20150618 16:47:39 <sgothel> alsa / pulse config .. nightmarish ..
20150618 16:48:30 <sgothel> on one system I had to pull pulseaudio completly, which was always overriding my custom setting, i.e. no custom settings possible - or maybe .. if you have a PhD for it :)
20150618 17:00:18 * jvanek (jvanek@anon) Quit (Quit: Leaving)
20150618 17:17:51 * doev (~doev@anon) has joined #jogamp
20150618 17:35:35 * doev (~doev@anon) Quit (Ping timeout: 276 seconds)
20150618 17:36:09 <bruce-> it was reason enough for me to walk away from linux entirely
20150618 18:19:23 * monsieur_max (~maxime@anon) has joined #jogamp
20150618 18:30:49 * mbien (~mbien@anon) has joined #jogamp
20150618 21:44:34 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150618 22:57:39 * mbien (~mbien@anon) Quit (Quit: Leaving.)
20150619 03:25:44 * odin_ (~Odin@anon) Quit (Ping timeout: 272 seconds)
20150619 03:34:47 * odin_ (~Odin@anon) has joined #jogamp
20150619 05:05:59 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20150619050559.html