#jogamp @ irc.freenode.net - 20160524 05:06:24 (UTC)
20160524 05:06:24 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20160523050624.html
20160524 05:06:24 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20160524050624.html
20160524 05:47:52 * bigpet (uid25664@anon) has joined #jogamp
20160524 06:02:20 * SHC (~quassel@anon) has joined #jogamp
20160524 06:56:05 * elect (~GBarbieri@anon) has joined #jogamp
20160524 06:58:38 <elect> hey
20160524 07:30:33 * monsieur_max (~maxime@anon) has joined #jogamp
20160524 07:34:27 * Eclesia (~husky@anon) has joined #jogamp
20160524 07:34:34 <Eclesia> hi
20160524 08:49:14 <elect> hi
20160524 09:02:32 * jvanek (jvanek@anon) has joined #jogamp
20160524 09:16:36 <elect> someone has some experience with jogl and javafx?
20160524 09:20:22 <monsieur_max> + "and still sane enough to speak about it"
20160524 09:21:05 <zubzub> experience?
20160524 09:21:18 <zubzub> as in you can hardly use both of them in the same window?
20160524 09:21:43 <monsieur_max> :)
20160524 09:50:00 <rmk0> i meant to ask why that isn't possible...
20160524 09:52:09 <zubzub> everything is possible if you want
20160524 09:52:19 <zubzub> question is how stable will your solution be and how much work is it
20160524 09:53:02 <rmk0> well, yes. i just assumed from what i'd heard in here in the past that it was actually impossible to implement something like GLCanvas
20160524 09:53:23 <rmk0> wasn't sure how they could have managed that
20160524 10:10:04 <xranby> There are many ways to make javafx and jogl work in the same application using the [SlowPath] https://jogamp.org/bugzilla/show_bug.cgi?id=607#c20 what have deemed hard is to have good [Static-UI-Separation]
20160524 10:11:07 <xranby> and strategies that are fast are [Fragile] with reduced [Portability]
20160524 10:14:39 <bruce-> afaik part of the problem is that the javafx implementation does not always use opengl
20160524 10:15:11 <xranby> here is the jury instructions on the oracle vs google case: https://www.scribd.com/doc/313560685/Jury-Instruction-Oracle-v-Google
20160524 10:16:01 <xranby> bruce-: some of the strategies is to first rewrite javafx to use OpenGL
20160524 10:16:20 <xranby> base it on jogl etc
20160524 10:17:08 <xranby> such as this implementation https://github.com/pepe1914/jfx-zoglpipeline
20160524 10:18:07 <xranby> Eclesia: ^ - this is public domain :)
20160524 10:18:59 <xranby> or do you call it tainted public domain that rely on non public domain parts
20160524 10:19:01 <xranby> ?
20160524 10:19:08 * Eclesia don't need javafx anymore
20160524 10:21:28 <zubzub> lukcly there are good alternatives to javafx
20160524 10:21:30 <zubzub> like
20160524 10:21:31 <zubzub> javafx
20160524 10:21:43 <zubzub> but that has the drawback that it is javafx
20160524 10:21:49 <zubzub> so you're stuck with javafx
20160524 10:44:37 <xranby> According to the Jury Instructions page 16 java re-implementation can use all API's listen in Trial Exhibit 9223: "It is established that 170 lines of code at issue are technically necessary to use the Java programming language. Those 170 lines of declaring code are listed in Trial Exhibit 9223. Because that declaring code is necessary to use the language, it is established that Google’s useof the declaring code in Trial Exhibit 9223 was a fair use."
20160524 10:45:20 <xranby> "It is for you to determine the extent to which other additional declaring code beyond those lines identified in Trial Exhibit 9223 either was or was not necessary for use of the Java programming language."
20160524 10:54:06 * xranby is looking for Trial Exhibit 9223 online
20160524 12:48:22 * jvanek (jvanek@anon) Quit (Quit: Leaving)
20160524 13:18:16 * jvanek (jvanek@anon) has joined #jogamp
20160524 13:43:04 <SHC> guys, can someone point me to using JOAL on android?
20160524 13:45:24 <SHC> I seem confused with this artifact: http://jogamp.org/deployment/maven/org/jogamp/joal/joal-android/2.3.2/joal-android-2.3.2-natives-windows-i586.jar
20160524 13:45:39 <SHC> windows natives on android artifact?
20160524 13:48:55 <xranby> SHC: jogamp's nature is to detect what kind of OS you are using at runtime, thus from jogamp's point of view its easier to assume such an android flavour appear in the future compared to trying to remove code from the android deployment jars
20160524 13:50:02 <SHC> I have an android only project, and I'm using android's built in GLSurfaceView to get OpenGL ES. Can I use only JOAL without JOGL?
20160524 13:50:37 <xranby> SHC: you can use JOAL without JOGL you only need JOAL and gluegen
20160524 13:50:54 * zubzub really hates the way one is supposed to detected what platform is running
20160524 13:51:31 <SHC> Thanks, and I cannot find how to setup this manually with Android Studio, are there any instructions? I'm using gradle by the way.
20160524 13:52:09 * SHC agrees completely with zubzub
20160524 13:52:32 <xranby> SHC: https://jogamp.org/wiki/index.php/Maven_And_Android
20160524 13:52:52 <xranby> that is the most compact guide how to use the jogamp maven artifacts with android
20160524 13:52:59 <xranby> however it is not joal specific
20160524 13:54:10 <zubzub> the problem is that there is *no* way to easily detected it
20160524 13:54:13 <zubzub> it's a pitty
20160524 13:54:18 <zubzub> and yet all the info is there
20160524 13:54:20 <zubzub> right in the vm
20160524 13:54:35 <zubzub> staticlly
20160524 13:55:01 <zubzub> while user code has to write all kinds of elf object dump parsing holy moly code to properly dynamically detect it
20160524 13:55:51 <zubzub> all the java has to do is declare a standard of os & arch enums that can be queried through the jvm
20160524 13:56:19 <xranby> the VM typically only know which OS and ARCH you are runnign on, it have no clue what Window Toolkit is to be used
20160524 13:56:25 <zubzub> and the jvm has to simply statically declare them internally (except if the same jvm binary can run on different platforms, in which case it has to handle it dynamically)
20160524 13:56:36 <zubzub> xranby: sure, that's good enough
20160524 13:56:53 <zubzub> that's the hardest part anyway
20160524 13:57:45 <zubzub> I always feel like java native support is severly lacking
20160524 13:57:57 <xranby> sometimes you can guess that if you are on windows then you are likely using the Windows Window Toolkit, however X11 on Windows is theoretically possible
20160524 13:58:05 <SHC> I feel like produce different runtimes in different artifacts, and let the user only include what artifacts he likes
20160524 13:58:11 <zubzub> and on linux you can have X and/or wayland
20160524 13:58:12 <zubzub> or fb
20160524 13:58:24 <SHC> by the way, what is this GlueGen?
20160524 13:58:25 <zubzub> SHC: yes me too
20160524 13:58:29 <xranby> or dispmanx (using broadcoms opengl on raspberry pi )
20160524 13:59:01 <xranby> SHC: GlueGen is the tool we use to generate java bindings from C headers
20160524 13:59:22 <SHC> So it is not required at runtime right?
20160524 13:59:25 <xranby> SHC: it is also a runtime part where we store all help classes required to detect what platform you are running on
20160524 13:59:27 <zubzub> it's a pretty limited jni glue code generator
20160524 14:00:21 <xranby> example. on linux gluegen contain an elf header parser so that we can load the right natives on arm linux systems where there exist many different variants of userspace ABI
20160524 14:00:42 <xranby> the VM do not report what ABI is in use on ARM linux systems
20160524 14:01:01 <xranby> thus the VM will say Linux ARM for both soft-float and hard-float arm linux systems
20160524 14:01:13 * zubzub 's solution is to let the user provide a vm property telling what arch to use
20160524 14:01:20 <zubzub> much simpler to implement ;0
20160524 14:01:32 <xranby> oracle is hard to convince
20160524 14:01:36 <zubzub> *system property
20160524 14:01:42 <zubzub> yeah well... oracle
20160524 14:01:46 <xranby> it have to be part of the specification
20160524 14:01:53 <zubzub> yup
20160524 14:01:58 <xranby> in Java 8 they did add a system property
20160524 14:02:03 <xranby> however not part of specification
20160524 14:02:29 <xranby> thus that is not something you can rely on
20160524 14:02:33 <zubzub> indeed
20160524 14:02:46 <zubzub> I really needed it for my own Jaccall project
20160524 14:02:50 <zubzub> so I basically went with my own
20160524 14:03:08 <xranby> and since we still support JDK 6 & android we did the elf parser solution that work everywhere
20160524 14:03:12 <zubzub> I looked at gluegen's elf parser but it's quite complex/big for something that's actually statically known
20160524 14:03:57 <zubzub> I'm actually impressed gluegen wrote it's own elf parser
20160524 14:04:02 <zubzub> without relying on external tools
20160524 14:04:32 <zubzub> but doesn't that limit it too the arch's it knows @ compile time?
20160524 14:04:33 <xranby> gluegen have a lot of bit manipulation API's
20160524 14:04:37 <xranby> naturally
20160524 14:05:14 <zubzub> can it be overriden?
20160524 14:05:28 <xranby> zubzub: yes, we can only support architectures we have built the native code for
20160524 14:06:12 <xranby> for example... if i want to support 64bit gnu linux arm systems .. i have to compile natives for that OS ARCH combination
20160524 14:07:16 <xranby> this is one combination i will extend support to
20160524 14:07:31 <zubzub> and how do I tell gluegen to use this native lib if it can't parse the elf header?
20160524 14:07:40 <zubzub> say I want to use it in an exotic arch
20160524 14:07:49 <zubzub> and I have the source for the native lib
20160524 14:07:57 <zubzub> I compile th enative lib
20160524 14:07:59 <xranby> in most cases you are fine with the JVM's OS ARCH
20160524 14:08:01 <zubzub> now I want gluegne to use it
20160524 14:08:11 <xranby> we only need to use the elf parser if there exist many types of userspace
20160524 14:08:43 <xranby> for the same OS ARCH cobination
20160524 14:09:00 <xranby> OS ARCH ABI Tookit
20160524 14:09:04 <xranby> Toolkit
20160524 14:09:11 <xranby> you need to know all four
20160524 14:10:23 <zubzub> toolkit?
20160524 14:10:30 <zubzub> for newt?
20160524 14:13:20 <xranby> zubzub: toolkit like in X11, Wayland...
20160524 14:13:40 <xranby> so that you pass the right native window type to opengl initialization
20160524 14:17:16 <zubzub> so that newt uses the correct initialization path for the underlying display platform
20160524 14:18:11 <xranby> yes
20160524 14:18:26 <xranby> not only for newt
20160524 14:22:00 <xranby> SHC: in JOAL's case gluegen unpacks and loads the bundled libopenal soft for use on android
20160524 14:22:42 <SHC> Is it possible to load the library manually by System.load("openal"); and avoid gluegen?
20160524 14:22:58 <SHC> Am asking this because my APK is already 37 MB
20160524 14:23:52 <xranby> the size of gluegen-rt shoudl not make much difference
20160524 14:24:11 <xranby> the answer is no, joal require it
20160524 14:26:13 <xranby> gluegen-rt-android-armv6.apk is 181K
20160524 14:26:30 <xranby> joal-android-armv6.apk is 214K
20160524 14:27:13 <xranby> thus adding JOAL will only increase your APK with 400k
20160524 14:31:10 <xranby> if maven bundle more than that then we need to look into why
20160524 14:33:19 <xranby> SHC: these are the sized of the JogAmp test APK's we create for each release http://jogamp.org/deployment/v2.3.2/apk/ using maven should produce APK's with similar numbers. We only show that jogamp modules can be used as slit up jars similar to on desktop here.. however it is possible to make one android apk with the contents from all jars into one using maven
20160524 14:34:10 <xranby> split up apk's
20160524 14:42:39 * guillaum1 (~gl@anon) Quit (*.net *.split)
20160524 14:42:41 * monsieur_max (~maxime@anon) Quit (*.net *.split)
20160524 15:15:06 <elect> dumb question
20160524 15:15:24 <elect> how can I see the String representation of this in C
20160524 15:15:24 <elect> void* compressed_ttf
20160524 15:26:14 <zubzub> what do you mean?
20160524 15:26:19 <zubzub> you have a void pointer
20160524 15:26:31 <zubzub> and you want it to be converted to a String in java?
20160524 15:27:08 <zubzub> or do you want to print(f) that void pointer in C?
20160524 15:27:34 <zubzub> if so, do you want to see the address itself or the contents represented as a char pointer?
20160524 15:27:58 <zubzub> I DON'T KNOW WHAT YOU WANT MAN :'(
20160524 15:27:59 <zubzub> ;)
20160524 15:33:09 <zubzub> anyway
20160524 15:33:26 <zubzub> I can answer all those questions for you but the truth is out there (google)
20160524 15:33:31 <zubzub> + I have to go now
20160524 15:33:34 <zubzub> o/
20160524 15:34:44 * jvanek (jvanek@anon) Quit (Quit: Leaving)
20160524 15:40:15 * monsieur_max (~maxime@anon) has joined #jogamp
20160524 15:45:51 * guillaum1 (~gl@anon) has joined #jogamp
20160524 15:46:30 * elect (~GBarbieri@anon) Quit (Ping timeout: 276 seconds)
20160524 15:48:56 * elect (~elect@anon) has joined #jogamp
20160524 15:50:05 * elect (~elect@anon) Quit (Remote host closed the connection)
20160524 15:57:36 * guillaum1 (~gl@anon) Quit (*.net *.split)
20160524 16:00:48 * Eclesia (~husky@anon) has left #jogamp
20160524 16:05:46 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20160524 16:06:14 * guillaum1 (~gl@anon) has joined #jogamp
20160524 17:43:35 * Eclesia (~eclesia@anon) has joined #jogamp
20160524 17:50:35 * monsieur_max (~maxime@anon) has joined #jogamp
20160524 18:16:42 * guillaum1 (~gl@anon) Quit (Ping timeout: 258 seconds)
20160524 18:17:38 * guillaum1 (~gl@anon) has joined #jogamp
20160524 18:42:08 * SHC (~quassel@anon) Quit (Remote host closed the connection)
20160524 19:59:25 * xranby1 (~familjen@anon) has joined #jogamp
20160524 20:07:29 <xranby1> The oracle vs google case right now.. Jury complains while trying to review the 15 million lines of java code evidence that "You open that up, there's folder. You open that, there's another folder. You open that, there's four more folders."
20160524 20:09:41 <xranby1> Well, apparently court computers aren't installed with programs for writing / reviewing Java.
20160524 20:57:57 <Eclesia> poor jury members
20160524 21:06:58 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20160524 21:26:01 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20160524 22:22:57 * bigpet (uid25664@anon) Quit (Quit: Connection closed for inactivity)