#jogamp @ irc.freenode.net - 20150827 05:05:31 (UTC)

20150827 05:05:31 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20150826050531.html
20150827 05:05:31 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20150827050531.html
20150827 06:03:32 * monsieur_max (~maxime@anon) has joined #jogamp
20150827 06:13:50 * elect (~elect@anon) has joined #jogamp
20150827 06:14:03 <elect> hi
20150827 06:33:22 * jvanek (jvanek@anon) has joined #jogamp
20150827 07:05:29 * eclesia (~husky@anon) has joined #jogamp
20150827 07:05:35 <eclesia> good morning
20150827 07:17:32 <xranby> good morning
20150827 07:17:58 <xranby> elect: hi, netbeans you say... i can take a quick look
20150827 07:18:45 <elect> hi xranby, I'll be back asap
20150827 07:20:13 <xranby> gluegen -> click build -> build sucessful
20150827 07:26:30 <xranby> jogl -> click build -> build sucessfull
20150827 07:27:13 <xranby> netbeans may think it cant find some class and underline.. but try ignore that.. since when you build you run the regular ant
20150827 07:27:37 <xranby> elect: i think you get upset by red markings done by netbeans
20150827 07:27:52 <elect> definitely
20150827 07:29:00 <xranby> elect: do not let netbeans auto correct jogl code ..
20150827 07:29:13 <xranby> because if you do that then the ant build will likely fail
20150827 07:29:44 <xranby> since the code is infact correct as you have verified using ant
20150827 07:33:32 <xranby> elect: the reason why netbeans is upset is
20150827 07:33:45 <xranby> elect: that we generate some classes during the build
20150827 07:33:56 <xranby> elect: and netbeans do not know this
20150827 07:34:11 <xranby> this makes netbeans think some classes are missing
20150827 07:34:46 <xranby> trying to please netbeans in this case will only make it worse :)
20150827 07:35:18 <xranby> i read from what you wrote on the forum that you tried to please netbeans by adding the jogl jars etc
20150827 07:35:21 <xranby> dont do that :)
20150827 07:38:44 <elect> no, that was wrong, brb
20150827 07:47:52 <xranby> elect: net beans have a section called Project -> properties -> Java Sources Classpath i think it may be safe to add the location of the build/gensrc/java here since it would remove some red marking in the ide without breaking the build
20150827 08:00:02 * gouessej (5ee4b442@anon) has joined #jogamp
20150827 08:00:06 <gouessej> Hi
20150827 08:00:16 <gouessej> eclesia: Good job :)
20150827 08:00:42 <eclesia> still not good enough for small fonts
20150827 08:01:12 <gouessej> elect: I'll add some information about URL rewriting into the bug report, I advise you to read them and to give it a try if I don't have enough time to do so
20150827 08:01:56 <elect> y
20150827 08:02:00 <elect> brb
20150827 08:05:24 <gouessej> elect: brb?
20150827 08:05:45 <eclesia> be right back ?
20150827 08:05:48 <elect> y
20150827 08:05:57 <gouessej> ok
20150827 08:47:43 <elect> ok
20150827 08:47:45 <elect> so
20150827 08:48:06 <elect> xranby, so you also have the red markings and you just dont care?
20150827 08:48:35 <xranby> yes, if you look carefull you can see that some marking is because i do not have the android sdk installed
20150827 08:48:56 <gouessej> elect: me too, in Eclipse
20150827 08:48:57 <xranby> most marking are because they refer to classes generated during the build
20150827 08:49:12 <xranby> and i do not get upset by this techicality
20150827 08:49:23 <xranby> technicallity
20150827 08:49:34 <gouessej> Sometimes, refreshing the project after a first build is enough to get rid of them
20150827 08:49:45 <gouessej> or at least most of them
20150827 08:49:50 <xranby> i think it looks better in eclipse compared then netbeans
20150827 08:49:56 <xranby> compared to netbeans
20150827 08:49:57 <elect> I already tried to adopt all the passages of Eclipse here https://jogamp.org/wiki/index.php/Building_JOGL_in_Eclipse#Create_the_gluegen_project_.28optional.29
20150827 08:50:15 <elect> this includes the build/gensrc/java as well
20150827 08:50:23 <elect> but many red remain
20150827 08:50:45 <elect> ok
20150827 08:51:21 <elect> this should be written in the wiki
20150827 08:51:43 <elect> I always assumed the red mark as an malfunctional building
20150827 08:51:50 <xranby> we naturally do not write what we do not do :)
20150827 08:52:12 <xranby> if we do not get upset we do not write it
20150827 08:52:17 <elect> well, sometimes you should if it is something like that
20150827 08:52:26 <elect> no, look, I also didnt really got upset
20150827 08:52:36 <elect> but it costed a lot of your and mine time
20150827 08:52:54 <gouessej> I built JOGL with Ant in command line first
20150827 08:52:54 <elect> so maybe just a line advising red marks are normal is enough
20150827 08:53:17 <elect> me too, then I went back to Netbeans and saw the red signs
20150827 08:53:21 <gouessej> The IDE is optional, it's just more comfortable
20150827 08:54:21 <elect> I never saw a dev not using an ide to code
20150827 08:54:23 <gouessej> I understand your position, that's why I did my best not to do the same in JogAmp's Ardor3D Continuation, there is nothing in red, it uses Maven, it's straightforward
20150827 08:54:49 <elect> you can use a simple editor or a console editor, but seriously
20150827 08:54:52 <gouessej> elect: I used a simple text editor for several years and I can live without an IDE for sure
20150827 08:55:27 <gouessej> elect: When something goes wrong, you have to understand your tools to make it work, not to become a slave of an IDE
20150827 08:55:39 <elect> I cant believe it is in any way feasible on projects such large and big as jogamp
20150827 08:55:59 <elect> it is just masochism
20150827 08:56:19 <gouessej> elect: Look at the build scripts, so much things are generated
20150827 08:57:27 <gouessej> elect: I think that it's very difficult to achieve on the projects with generated classes and resources
20150827 08:57:59 <elect> is there a reason to generate those classes/resources in the build?
20150827 08:58:00 <gouessej> elect: and it's not an end after all. It works with Ant, it's ok for me.
20150827 08:58:20 <gouessej> elect: yes
20150827 08:59:23 <gouessej> I use Git in command line, I have had less troubles than with EGit
20150827 09:00:13 <elect> anyway, which ide do you use?
20150827 09:00:44 <gouessej> In my humble opinion, swithching to Maven might fix this kind of problem but it wouldn't be trivial
20150827 09:00:58 <gouessej> I use mainly Eclipse and a bit Netbeans
20150827 09:01:06 <elect> you mean all the red markings?
20150827 09:01:12 <gouessej> yes
20150827 09:02:04 <gouessej> they would just appear for a few seconds during the build or they would remain hidden as Eclipse would wait for the end of the build to update the warnings
20150827 09:05:06 <elect> and regarding Discourse
20150827 09:05:39 <gouessej> What about Discourse?
20150827 09:06:24 <elect> you create those rules in apache
20150827 09:06:43 <elect> but Discourse I guess it is using another one
20150827 09:06:49 <elect> so you will have to run both
20150827 09:06:51 <elect> ?
20150827 09:07:01 <elect> Ngix I gues
20150827 09:07:02 <elect> s
20150827 09:09:14 <gouessej> It's possible to do something similar with Nginx but as far as I know it's possible to install Discourse on an Apache server
20150827 09:09:58 <gouessej> https://meta.discourse.org/t/how-to-set-up-discourse-on-a-server-with-existing-apache-sites/30013
20150827 09:10:31 <elect> what is using nabble right now?
20150827 09:10:34 <elect> Apache?
20150827 09:11:40 <gouessej> Nabble isn't self-hosted, is it?
20150827 09:12:01 <elect> dunno, I thought sven were hosting it
20150827 09:14:58 <elect> I was also thinking about porting the new bullet3 to jogl
20150827 09:15:11 <elect> jbullet looks dead and obsolete
20150827 09:15:27 <elect> and its code is not on github or whatever
20150827 09:15:42 <elect> we could use java 100% using jocl
20150827 09:16:46 <elect> what do you think, gouessej?
20150827 09:16:56 <elect> it'd be confortable also for your tuer
20150827 09:17:04 <elect> and many other java game devs
20150827 09:17:18 <gouessej> There are already some working forks
20150827 09:17:30 <gouessej> Look at my posts about it on Stackoverflow
20150827 09:18:23 <gouessej> One of them is on Github
20150827 09:18:45 <gouessej> JBullet has an high memory footprint
20150827 09:19:05 <elect> I know, I read also a couple of users complaining about some leaks
20150827 09:19:12 <elect> creating a lot of classes in some loops
20150827 09:19:35 <gouessej> Its author wrote numerous great APIs
20150827 09:19:41 <gouessej> PureSwing :)
20150827 09:20:02 <gouessej> His FPS uses shaders everywhere
20150827 09:20:02 <elect> cant find your post on Stacko
20150827 09:21:26 <gouessej> https://github.com/bubblecloud/jbullet
20150827 09:21:38 <gouessej> http://stackoverflow.com/questions/31879084/java-create-world-collision-with-heightmap-jbullet
20150827 09:25:01 <gouessej> You can still create your own Bullet binding with GlueGen
20150827 09:25:56 <elect> is there any material explaining how to do that?
20150827 09:26:25 <gouessej> http://jogamp.org/gluegen/doc/manual/
20150827 09:26:51 <gouessej> It's not completely up-to-date
20150827 09:27:31 <gouessej> The fork above no longer uses "StackAlloc"
20150827 09:27:33 <elect> do you think the effort to create the bindings is better to port everything to java?
20150827 09:28:58 <gouessej> "better" is subjective. A port would require a bigger maintenance effort on the long term but it would be easier to use.
20150827 09:29:37 <gouessej> It depends on the evolution of Bullet
20150827 09:29:59 <elect> I saw all the activities around joml, I'd like to do something similar for jbullet3
20150827 09:30:21 <gouessej> There are already tons of Java math libraries
20150827 09:30:46 <bruce-> are there any good ones? :)
20150827 09:31:13 <elect> yep, but this seems really focusing on performances
20150827 09:31:16 <gouessej> ardor3d-math has been tested during several years
20150827 09:31:37 <gouessej> JOGL itself contains some utilities
20150827 09:31:44 <elect> I know
20150827 09:31:44 <bruce-> oh that kind of math
20150827 09:35:17 <gouessej> Actually, joml does what other libraries do and it has something close to PMVMatrix
20150827 09:35:56 <elect> I was looking at jme, it uses the old jbullet
20150827 09:36:42 <gouessej> not only this thing
20150827 09:36:54 <gouessej> JMonkeyEngine 3 has its own native Bullet binding
20150827 09:37:00 <gouessej> but numerous methods are missing
20150827 09:39:06 <gouessej> joml focuses on performance but I assume that you can get a similar speed with specialized math libraries I quote on JGO and several much more limited ones including some libraries inspired of vecmath
20150827 09:55:25 * monsieur_max (~maxime@anon) Quit (Ping timeout: 245 seconds)
20150827 09:58:01 * gouessej (5ee4b442@anon) Quit (Quit: Page closed)
20150827 09:59:36 * monsieur_max (~maxime@anon) has joined #jogamp
20150827 10:42:13 * xranby (~xranby@anon) has left #jogamp
20150827 10:43:47 <elect> I didnt know this website, http://delphigl.de
20150827 11:22:05 <rmk0_> i'd be vaguely interested to know how my jtensors package stacks up
20150827 11:22:23 <rmk0_> i don't have the time or knowledge to benchmark it against all the rest
20150827 11:36:40 <rmk0_> i've been considering pooled variants of the existing vector types
20150827 11:36:57 <rmk0_> as in, each vector value is just an index into a large bytebuffer pool
20150827 11:37:54 <rmk0_> it's unsafe, but it would drastically reduce garbage in code that allocates tons of short lived vectors
20150827 11:38:21 <rmk0_> the vectors could implement Closeable and be managed with try-with-resources
20150827 11:38:48 <rmk0_> i think direct bytebuffers should have been... they are a finite resource
20150827 11:39:05 <rmk0_> the Unsafe direct bytebuffer cleaner could have been avoided
20150827 12:56:36 * gouessej (5ee4b442@anon) has joined #jogamp
20150827 12:56:55 <gouessej> rmk0_ :"the Unsafe direct bytebuffer cleaner could have been avoided" How?
20150827 12:57:16 <gouessej> rmk0_: it's up to you to manage the native memory
20150827 12:59:36 <rmk0_> gouessej: i mean that i think native byte buffers should have been treated as closeable resources. it would have cleared up all the management problems that the jvm has with them, because users would be required to close them and the contract would specify undefined results if they try to access "closed" buffers
20150827 12:59:42 <rmk0_> or fail fast results, whatever
20150827 12:59:59 <rmk0_> it's obviously too late now
20150827 13:01:18 <rmk0_> it would have been even more appropriate for memory-mapped file-backed bytebuffers
20150827 13:16:06 <gouessej> it's not too late
20150827 13:17:04 <gouessej> It was planned to ditch Unsafe as a whole but Cleaner will survive. Initially, Oracle seemed to plan to provide another API for the direct NIO buffers
20150827 13:23:51 <gouessej> I would prefer that it implements AutoCloseable
20150827 13:27:58 <gouessej> but closing an indirect NIO buffer would be absurd
20150827 13:56:56 <rmk0_> yeah, there's no need to close a buffer that's on the heap
20150827 13:57:28 <rmk0_> their problem stems from the fact that they use mmap() underneath, and rely on finalization to munmap()
20150827 13:57:41 <rmk0_> and it doesn't happen promptly enough, requiring use of the cleaner
20150827 13:58:00 <rmk0_> they shouldn't have been represented by the same type... should have shared a common bytebuffer interface
20150827 14:14:17 <gouessej> Not all direct byte buffers use mmap underneath, do they?
20150827 14:15:23 <rmk0_> i don't think it's guaranteed, but the symptom is the same
20150827 14:18:36 * gouessej (5ee4b442@anon) Quit (Ping timeout: 246 seconds)
20150827 14:19:03 * rmk0_ is now known as rmk0
20150827 14:19:07 * rmk0 (~rmk0@anon) Quit (Changing host)
20150827 14:19:07 * rmk0 (~rmk0@anon) has joined #jogamp
20150827 14:27:31 * xranby (~xranby@anon) has joined #jogamp
20150827 14:59:03 <a11mad11> elect : my vao code work with your example but it doesn't work with my code...
20150827 15:02:55 <a11mad11> now all work tanks
20150827 15:24:41 <elect> you solved ?
20150827 15:24:48 * elect (~elect@anon) Quit (Read error: Connection reset by peer)
20150827 15:35:52 * eclesia (~husky@anon) Quit (Quit: Leaving.)
20150827 15:38:15 * elect_ (~elect@anon) has joined #jogamp
20150827 15:42:34 * a11ma11 (~marc-anto@anon) has joined #jogamp
20150827 15:42:54 * a11ma11 (~marc-anto@anon) has left #jogamp
20150827 15:43:03 * a11mad11 (c0e2cd65@anon) Quit (Quit: Page closed)
20150827 15:43:32 * a11ma11 (~marc-anto@anon) has joined #jogamp
20150827 15:44:36 * a11ma11 (~marc-anto@anon) Quit (Client Quit)
20150827 15:44:40 * a11mad11 (~marc-anto@anon) has joined #jogamp
20150827 15:48:19 * a11mad11 ** SysInfo ** Client: HexChat 2.10.2 (x64) ** OS: Microsoft Windows 8.1 ** CPU: Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz (2.00 GHz) ** RAM: 8071 MB Total (3125 MB Free) ** VGA: Intel(R) HD Graphics 4000 ** Uptime: 57.84 Hours **
20150827 15:52:42 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150827 15:53:44 * jvanek (jvanek@anon) Quit (Quit: Leaving)
20150827 16:28:12 * Eclesia (~eclesia@anon) has joined #jogamp
20150827 16:46:41 <elect_> sgothel, then I'll work on my locally jogl
20150827 16:47:00 <elect_> and then I just push when I am done?
20150827 16:47:10 <elect_> with all the comments
20150827 16:50:21 <xranby> elect_: yes, push to one of your own public gits.
20150827 16:51:08 <elect_> what you mean by own git? Shall I first clone it through github?
20150827 16:51:15 <xranby> exactly
20150827 16:51:18 <elect_> ok
20150827 16:52:19 <xranby> when you are working with your local git you can add many remotes
20150827 16:52:22 <xranby> example
20150827 16:52:25 <xranby> i do
20150827 16:52:30 <xranby> git fetch jogamp
20150827 16:52:38 <xranby> to fetch from the jogamp git
20150827 16:52:55 <elect_> ah, and then you push into your github clone
20150827 16:53:09 <elect_> and then when you are ready you push to the sven jogl?
20150827 16:53:25 <xranby> git remote add elect https://github.com/elect86/jogl
20150827 16:53:43 <xranby> and then when you want to push a branch to your git you do
20150827 16:53:46 <xranby> git push elect86 master
20150827 16:53:51 <xranby> or git push elect86 BugXXX
20150827 16:54:21 <xranby> sorry some typos in the lines above.. but i think you get the idea
20150827 16:54:25 <elect_> yes
20150827 16:54:27 <elect_> thanks
20150827 16:55:10 <xranby> when you are ready then you can press the "crate pull request" button on github
20150827 16:55:38 <xranby> and we will review and start comment the proposed changes
20150827 16:55:47 <elect_> ok
20150827 16:55:52 <xranby> if everything looks great it will get merged
20150827 16:57:08 <xranby> git fetch <- is nice it allows me to download your changes without merging them with my changes
20150827 16:57:28 <xranby> etc
20150827 16:57:58 <xranby> i use git branch to jump between your branches and my banches
20150827 16:58:15 <xranby> example say that you have pushed some changes to your master that i want to test
20150827 16:58:20 <xranby> git fetch elect
20150827 16:58:27 <xranby> git checkout elect/master
20150827 16:58:47 <xranby> ... then i can do testing etc of your changes
20150827 16:58:56 <xranby> and when i am done i can switch back to my master
20150827 16:59:00 <xranby> git checkout master
20150827 17:00:06 <elect_> yep
20150827 17:09:33 <sgothel> @elect: best you create an explicit branch for me to merge, containing all your changes
20150827 17:10:05 <sgothel> then you send me an email, which branch you like me to merge (or notify me here, enough if I respond!)
20150827 17:10:39 * monsieur_max (~maxime@anon) has joined #jogamp
20150827 17:11:25 <elect_> ok
20150827 17:12:16 <xranby> hmm the old jackpot JOGL 1 -> JOGL 2 conversion thingies still uses the javax syntax i wonder if people still use them
20150827 17:27:27 * elect_ (~elect@anon) Quit (Ping timeout: 256 seconds)
20150827 17:37:06 <xranby> sgothel: i have a ImmModeSink question about how ImmModeSink handle NPOT textures on OpenGL ES 1 hardware (that only support POT textures). The code renders a QUAD using ImmModeSink as intended to fill the screen. this work great on desktop devices that support NPOT textures, however on the raspberry pi ImmModeSink do not emulate the functionality of desktop opengl and uses the texture coordinates of the extended power of two memory area: causing a lot
20150827 17:38:13 <xranby> https://github.com/xranby/MultisampleDemoES1 <- code and launch scripts that download the texture etc
20150827 17:38:47 <xranby> i got this code from a raspberry pi user who was confused since the code did not behave identical on all his systems
20150827 17:40:38 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=1203 <- and the other one .. in progress
20150827 17:42:07 <sgothel> what has ImmModeSink todo w/ textures .. i.e. explicitly ?
20150827 17:42:35 <sgothel> IMHO .. the confusion is, that we 'just' don't simulate non existing NPOT, i.e. a test case works where NPOT is supported
20150827 17:42:39 <sgothel> IMHO .. thats all
20150827 17:42:49 <sgothel> user shall ensure that NPOT is supported
20150827 17:43:00 <sgothel> maybe that is the tricky part here ?
20150827 17:44:30 <xranby> i am brainstorming if ImmModeSink may help out by maping from glTexCoord2f(1.0f, 1.0f)  to the textures "real" coordinates like glTexCoord2f(0.8f, 0.5f)
20150827 17:45:13 <sgothel> if you have bloated your texture in the first place to reach NPOT (using updateTex2D .. (sic))
20150827 17:45:14 <sgothel> yes
20150827 17:45:30 <sgothel> that is the common workaround for no NPOT
20150827 17:45:48 <sgothel> surely not really ImmModeSink's job
20150827 17:46:11 <sgothel> NPOT is supported on all >= ES2
20150827 17:46:33 <sgothel> GLContext.isNPOTTextureAvailable()
20150827 17:46:35 <xranby> ok then i put this in the it wokred as expected on POT only ES 1 drivers
20150827 17:46:57 <xranby> i wrote this answer https://www.raspberrypi.org/forums/viewtopic.php?p=808135#p808135
20150827 17:47:03 <xranby> and the user seems happy with it
20150827 17:47:46 <sgothel> I am afraid the incoming patches to Bug 1203 need good verification on all platforms .. hmm
20150827 17:48:20 <sgothel> sure .. I will be careful and will push commits as small as possible .. oh dear, so: REVIEW of those is very welcome (as usual for all patches)
20150827 17:48:33 <xranby> thank you for heads up
20150827 17:52:17 <xranby> sgothel: zubzub is surely happy to test each EGL detection improvement
20150827 17:53:25 <sgothel> @zuzub: if you can point me to your extension getEGLDevice usage .. I may can inject this change (EGLDisplayUtil ..)
20150827 17:53:33 <sgothel> while we are at it ..
20150827 17:54:18 <xranby> although i think he mostly wants to test gbm/EGL initialization https://www.khronos.org/registry/egl/extensions/MESA/EGL_MESA_platform_gbm.txt
20150827 17:54:42 <sgothel> EGL_*_platform_* <- .. right
20150827 17:55:16 <sgothel> one generic w/ API func entry, others for each platform w/ new token or so
20150827 17:55:36 <xranby> https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_platform_base.txt
20150827 17:55:47 <xranby> This extension defines functionality and behavior for EGL implementations that support multiple platforms at runtime. For example, on Linux an EGL implementation could support X11, Wayland, GBM (Generic Buffer Manager), Surface Flinger, and perhaps other platforms.
20150827 17:55:59 <sgothel> ay
20150827 17:56:05 <xranby> thats the one
20150827 18:03:21 <xranby> https://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_client_extensions.txt
20150827 18:03:25 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=1202 <- almost forgot .. all in wiki/release
20150827 18:03:36 <xranby> A client extension adds functionality that is independent of any display. In other words, it adds functionality to the EGL client library itself. This is a new type of extension defined by EGL_EXT_client_extensions. EGL_EXT_client_extensions is itself a client extension.
20150827 18:04:15 * elect_ (~elect@anon) has joined #jogamp
20150827 18:04:16 <sgothel> we sort of merge them in GLContext's extension-cache
20150827 18:04:41 <sgothel> in GLX we do handle them separately .. have to double check
20150827 18:21:25 <xranby> i will take a looka t this after 2.3.2 https://github.com/Sturmflut/ubuntu-touch-glmark2/blob/master/how_to_build_glmark2_for_ubuntu_phone.txt contains all changes needed to be done to glmark2 in order to make it run on the ubuntu phone
20150827 18:21:35 <xranby> https://github.com/glmark2/glmark2/commits/master
20150827 18:22:19 <xranby> inventing new api, that keeps evolving it seems, they do like things to break?
20150827 18:45:36 * Eclesia raise the hammer and has a look at the layout api he's breaking :x
20150827 19:10:07 * a11mad11_ (~marc-anto@anon) has joined #jogamp
20150827 19:13:27 * a11mad11 (~marc-anto@anon) Quit (Ping timeout: 255 seconds)
20150827 19:21:16 <Eclesia> xranby: I made a sweet builder, different from the one you show me. tada : http://unlicense.developpez.com/gallery/VID3D_AnimationAPI.ogv
20150827 19:22:16 <Eclesia> and the code : http://pastebin.com/S2ifV6r8
20150827 19:23:18 <Eclesia> it was too restrictive to have only 2 steps : 'from' , 'to'. this way we can make any number of keyframes
20150827 20:17:12 * xranby_ (~sabayonus@anon) has joined #jogamp
20150827 20:22:57 <xranby_> Eclesia: Nice API experiment! These builder patterns makes me start thinking if builder patterns are suitable for other topics than animation
20150827 20:24:13 <xranby_> like for example hot to build a state-machine or some event driven machine
20150827 20:25:27 <xranby_> what i do like is that the syntax is clear to read without nested if else blocks
20150827 20:26:17 <xranby_> i have to flood the channel for everyone to read
20150827 20:26:32 <xranby_> TransformTimeSerie anim = new TransformTimeSerieBuilder()
20150827 20:26:34 <xranby_> .on(space).repeat(0).timer(new DefaultTimer(20))
20150827 20:26:36 <xranby_> .at(0).translation(50, 50)
20150827 20:26:38 <xranby_> .at(2000).translation(400, 200).rotation(Angles.degreeToRadian(170)).scale(3)
20150827 20:26:40 <xranby_> .at(3000).translation(500, 500).rotation(Angles.degreeToRadian(0)).scale(0.5)
20150827 20:26:42 <xranby_> .at(4000).translation(200, 350).rotation(Angles.degreeToRadian(320)).scale(5)
20150827 20:26:44 <xranby_> .at(6000).translation(50, 50)
20150827 20:26:46 <xranby_> .build();
20150827 20:26:48 <xranby_> anim.start();
20150827 20:27:34 <xranby_> Thats Eclesias anim builder API
20150827 20:40:58 <Eclesia> builder are generaly used for objects with many properties and ends up being immutable. it is not the case here, TransformTimeSerie is mutable and this 'builder' could be used on an existing object too. A name like 'TimeSerieHelper' or 'TimeSerieManipulator' would be more appropriate.
20150827 20:45:13 * elect_ (~elect@anon) Quit (Ping timeout: 256 seconds)
20150827 20:57:40 <xranby_> I saw a fantastic paper today about reverse neural networks today... A Neural Algorithm of Artistic Style http://arxiv.org/abs/1508.06576 http://arxiv.org/pdf/1508.06576v1.pdf
20150827 21:05:15 <sgothel> @Ecliesia: TransformTimeSerie instance immutable as 'build' by the builder ..
20150827 21:05:56 <sgothel> Hmm .. Maybe you can contrib that directly to jogl? Or I fetch that one .. looks nice.
20150827 21:06:24 <sgothel> TransformTimeSerie -> Animation maybe ? :)
20150827 21:06:43 <sgothel> (a common interface maybe)
20150827 21:23:31 <Eclesia> sgothel: Animation is a parent interface.
20150827 21:24:01 <Eclesia> TransformTimeSerie -> KeyFrameTimeSerie -> Animation
20150827 21:24:15 <sgothel> sweet
20150827 21:24:44 <Eclesia> same interfaces for skeleton/Joint animations
20150827 21:26:13 <Eclesia> sgothel: I haven't commit yet. broke my layout api to quickly test it ^^
20150827 21:27:39 <sgothel> AFAIK you allow a fallback BSD'ish license .. so all good. However, it would be awesome if you would push it yourself. Need to create a new JogAmp project later for this GraphUI though.
20150827 21:28:01 <sgothel> In case you don't want to push it .. can I push using your name as author, for the original commit?
20150827 21:28:07 <sgothel> (since you are the author?)
20150827 21:28:21 <Eclesia> (I am)
20150827 21:28:24 <sgothel> (and if the BSD'ish license assumption is correct)
20150827 21:28:30 <Eclesia> (it is)
20150827 21:29:28 <sgothel> sweet .. I just like to maintain the original author .. not claiming anything :)
20150827 21:32:46 <Eclesia> maybe it's selfish but is it possible (if you take the class) to leave it in public domain ? or do you have to contain all classes in jogamp under bsd ?
20150827 21:33:09 <Eclesia> just asking
20150827 21:33:17 <sgothel> I can add a section in our LICENSE header and put them under dual license ..
20150827 21:33:35 <sgothel> i.e. need the BSD'ish for countries where no PD is avail (Eurpoe)
20150827 21:33:50 <sgothel> and the *disclaimer* ofc :)
20150827 21:33:56 <sgothel> *no warranties*
20150827 21:33:59 <sgothel> OK?
20150827 21:34:26 <sgothel> i.e. any changes to those packages/sources can be backported
20150827 21:34:58 <sgothel> so no situation like BSD -> LINUX, LINUX -- NOT --> BSD
20150827 21:35:46 <Eclesia> that would be great, would make it easier to share code this way.
20150827 21:35:47 <sgothel> this particular piece may be part of GraphUI, new project/module - since I don't like to bloat JOGL here
20150827 21:35:51 <sgothel> great
20150827 21:36:07 <sgothel> however .. other stuff can be dealt similar, i.e. if you have something for JOGL
20150827 21:37:10 <sgothel> so .. in case I like to use your code, can I commit the original version using you as author?
20150827 21:37:38 <sgothel> while adding the license to the LICENSE file .. and in the header (dual license)
20150827 21:37:53 <sgothel> (that would be the 2nd commit, me as author - ofc)
20150827 21:38:39 <Eclesia> I'm fine with it.
20150827 21:38:44 <sgothel> thank you!
20150827 21:39:26 <Eclesia> it's public domain after all ^^
20150827 21:39:47 <sgothel> I need your permission, you granted it - thank you! :)
20150827 21:40:13 <sgothel> if it happens, I will notify you ofc!
20150827 21:40:22 <sgothel> back to 2.3.2 bugs .. yawn ..
20150827 21:40:46 <Eclesia> there is just a little something that would be good to clarify, where is the limit of what can go inside jogamp and what should not.
20150827 21:41:12 <Eclesia> that's the discution I had with xranby on the cpu rasterizer. that would pull a loooot of things
20150827 21:41:24 <sgothel> for example .. I like the model of your Animation above .. but I won't like to pull megabytes of math stuff
20150827 21:41:32 <xranby_> Eclesia: you asked this some days before, where is the boundary of the JogAmp API
20150827 21:41:33 <sgothel> i.e. I would replace it w/ what we have etc
20150827 21:41:46 <sgothel> i.e. minimize things
20150827 21:42:19 <sgothel> CPU font rasterer .. IMHO: no way, it would be the 2nd one - since we already have one AWT based ..
20150827 21:42:22 <Eclesia> xranby_: yes but didn't receive a clear answer, and I understand the limit a fuzzy since jogamp is turning into a toolkit
20150827 21:42:31 <sgothel> which IMHO should be generalized .. somewhat
20150827 21:42:53 <sgothel> and we have one font parser already imported ..
20150827 21:43:05 <sgothel> in short: no redundancies please
20150827 21:43:18 <sgothel> if a diff. tool is better than the existing one, then we shall replace it
20150827 21:43:19 <sgothel> etc
20150827 21:44:05 <sgothel> and personally .. you know it .. I stay on the low-level stuff side, i.e. less GC, less allocations .. less less less
20150827 21:44:40 <sgothel> the higher order OO stuff is reserved for JOGL's users - if that is there design
20150827 21:44:50 <sgothel> we shall be able to run on low resources
20150827 21:45:48 <xranby_> i like to define jogamp as a technology enabler, JogAmp is good at abstracting hardware, but these API with Graph and your work makes it also Abstract wetware *core technology ideas and concepts*
20150827 21:45:49 <sgothel> always depends on the case .. case by case
20150827 21:46:08 <sgothel> yes .. well put
20150827 21:46:19 <sgothel> hence the graph core remains in JOGL
20150827 21:46:27 <sgothel> and GraphUI is its own package/module
20150827 21:46:58 <sgothel> (currently GraphUI is a unit test :)
20150827 21:50:35 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150827 21:57:11 <xranby_> the reason i woul dlike to replace the awt based one is because one of the ideas of jogamp is portability
20150827 21:57:57 <xranby_> talking about the text renderer now
20150827 21:58:21 <sgothel> yeah .. hence graph's text-renderer
20150827 21:58:55 <sgothel> each font's glyph is a list of OutlineShapes
20150827 21:59:12 <sgothel> it may be rendered different on CPU .. if so desired
20150827 21:59:30 <xranby_> at one of our presentations one persion in the audience asked , what is the fallback? this question have tornmented me, if i got the question today i would say that every operating systemships with an opengl software fallback like mesa3d
20150827 21:59:34 <sgothel> (I also had an AWT-like geom thingy .. collecting it)
20150827 21:59:57 <sgothel> yes
20150827 22:00:28 <sgothel> personally - GL2ES2 is ofc a min. requirement, hence I need no explicit CPU based renderer
20150827 22:00:38 <sgothel> but .. my needs are not the needs of the world :)
20150827 22:00:53 <sgothel> but it may not fit in JOGL .. which is GL based
20150827 22:01:29 <xranby_> having clear lines dividing the modules under the jogamp umbrella is good
20150827 22:01:33 <xranby_> liek we do
20150827 22:02:08 <Eclesia> wait a few more years and I'll have a software GL in the project ... maybe
20150827 22:02:38 <sgothel> *eclesia pull request: mesa3d* lol :)
20150827 22:02:47 <xranby_> thus if i should guide the design decisions i face, taking the raspberry piunderlay transparency issue..
20150827 22:02:54 <xranby_> as a concrete example.
20150827 22:03:10 <xranby_> maybe i should simply go ask for the mesa3d software fallback to paint it ttransaprent
20150827 22:03:47 <sgothel> and later .. we will have the free software GL driver anyways
20150827 22:04:20 <xranby_> thus instead of using an X11 Window athe underlay i can pick an X11 GLWindow
20150827 22:04:45 <sgothel> the reason I like those hacks (X11 underlay .. for pi) - they prove versatility and robostness of the core functionality and API
20150827 22:05:08 <sgothel> or .. the lack of it, asking us to make it so :)
20150827 22:05:12 <xranby_> since that would remove the need to pull in the whole unlicense project in order to have a CPU fallback
20150827 22:05:57 <sgothel> come again - I missed that discussion, why do you need the CPU font renderer fallback?
20150827 22:06:01 <xranby_> showing the versatility is ofc good, like we need the versatility demonstrated
20150827 22:06:15 <xranby_> inside the Applet3 deployment
20150827 22:06:56 <xranby_> to show that by putting the applet boundary at the native window without adding a defined toolkit makes it universal for all toolkits to use
20150827 22:07:40 <sgothel> hmm
20150827 22:08:04 <xranby_> sgothel: to answer your question, there was two usecases 1. a CPU repaint that makes the pi underlay transparent if the overlay is transparent
20150827 22:08:53 <xranby_> 2. having a way to give the end user feedback if initialization fail
20150827 22:08:53 <xranby_> like a dialogue box describing why the GPU driver failed to initialize
20150827 22:08:53 <xranby_> etc
20150827 22:09:07 <sgothel> pi underlay should be transparent .. if requested (caps) .. hmm
20150827 22:09:11 <sgothel> (2) .. oh well
20150827 22:09:40 <sgothel> (1) we should pick the right visualid for transparency
20150827 22:09:42 <xranby_> sgothel: i requested transparent using caps, but unfortunally the window is still filled with opaque garbage
20150827 22:09:47 <sgothel> in NEWT Window
20150827 22:09:52 <sgothel> ah ..
20150827 22:10:08 <sgothel> b/c it has *NO CONTENT* :)
20150827 22:10:34 <sgothel> so we would 'simply' need a feature for NEWT X11 Window to add a colorbuffer / init it ..
20150827 22:10:43 <sgothel> (memset)
20150827 22:11:15 <sgothel> right now, it is assumed that GL handles the colorbuffer
20150827 22:11:42 <sgothel> so .. one extra flag in CapabilitiesImmutable: clear colorbuffer
20150827 22:11:49 <xranby_> ideal this feature would be usefull for other usecases ... like the Applet3 thats why i was juggling CPU fallbackin my mind to test how to slot in a CPU based existing toolkit
20150827 22:11:53 <sgothel> this will also suit security concerns
20150827 22:12:06 <xranby_> to react on the redraw request
20150827 22:12:14 <sgothel> where we show old content .. if not doing a GL thing
20150827 22:12:28 <sgothel> (its a driver issue .. but whatever)
20150827 22:12:47 <xranby_> yes. having a window cleared with a defined colour makes art users happy
20150827 22:12:52 <xranby_> like processing 3
20150827 22:13:16 <sgothel> I still question their use-case, i.e. they use GL .. so they can deal w/ it
20150827 22:14:06 <sgothel> timegap between window-visibility and GLEventListener.init(..) .. hmm
20150827 22:14:12 <xranby_> lets talk about the security concern
20150827 22:14:36 <xranby_> making uninitialized memory accessible
20150827 22:14:40 <sgothel> within that timegap .. it might be possible to read the garbage .. i.e. old stuff
20150827 22:14:44 <sgothel> yes
20150827 22:15:06 <sgothel> this has been discussed a while ago .. should be done by driver
20150827 22:15:08 <sgothel> however ..
20150827 22:15:36 <sgothel> so at least we could blank: opaque = black, transparent = alpha:=0
20150827 22:15:44 <sgothel> w/i API change
20150827 22:15:48 <sgothel> w/o
20150827 22:15:58 <sgothel> in NEWT
20150827 22:16:52 <sgothel> for example a users GLEL.init(..) method could intentionally read out framebuffer ..
20150827 22:17:05 <sgothel> so we would need to clear it once after creation (using OpenGL)
20150827 22:17:27 <sgothel> for your use case, we could add a NEWT flag, whether this should be done by X11/...
20150827 22:17:54 <xranby_> is there users who do not want it cleared_
20150827 22:17:58 <xranby_> ?
20150827 22:18:12 <sgothel> like: I don't want to use a password :)
20150827 22:18:38 <sgothel> well .. I guess thats why we are here, dictating the world :)
20150827 22:18:54 <sgothel> if this addresses the security issue - there shall be no choice ofc
20150827 22:19:18 <sgothel> then - the colorbuffer shall be cleared *before* visibility
20150827 22:19:36 <sgothel> otherwise an external tool could copy content
20150827 22:19:53 <sgothel> so another hook NEWT <-> GLWindow
20150827 22:20:05 <sgothel> and the option to do it in CPU, if hook is n/a
20150827 22:20:22 <sgothel> and all of that non-optional
20150827 22:20:50 <sgothel> then we can discuss to allow an optional clear color for just that mem-fill :)
20150827 22:21:05 <sgothel> sound like a new Bug entry?
20150827 22:21:31 <sgothel> or more like *Sven's over-engineering* :)
20150827 22:25:24 * xranby_ (~sabayonus@anon) Quit (Read error: Connection reset by peer)
20150827 22:26:10 * xranby_ (~sabayonus@anon) has joined #jogamp
20150827 22:26:40 <xranby_> don't we have one already, the bug added by andreas for the processing enhancement?
20150827 22:26:48 <xranby_> thinking we may file it as more work under the same
20150827 22:27:04 <sgothel> nah .. the angle is different
20150827 22:27:17 <sgothel> but will mark it as dependent ..
20150827 22:27:28 <sgothel> use processing ones for the optional clear-color
20150827 22:27:38 <sgothel> the above one .. is more in detail
20150827 22:27:42 <sgothel> so you are fine w/ it?
20150827 22:27:53 <sgothel> then I add it .. for 2.3.2
20150827 22:28:04 <xranby_> i am happy for any solution that clear the opaque garbage :)
20150827 22:28:24 <sgothel> then you can also make your other one depend on this one ..
20150827 22:28:25 <xranby_> and fixes security at the same time
20150827 22:28:35 <sgothel> well .. the design and reasoning .. I meant :)
20150827 22:29:36 <xranby_> the workflow is excellent, withevery commit having a link to the bug/enhancement and vice versa
20150827 22:30:00 <sgothel> ofc :)
20150827 22:30:12 <xranby_> yes i like the design and reasoning very much thank you
20150827 22:31:08 <xranby_> it also hopefully satisfies Eclesia's concern how we define the boundarys of the jogamp modules
20150827 22:31:51 * Eclesia reading
20150827 22:32:02 <xranby_> right now i want to use unlicense as one of the toolkits to try plugin into the architecture without pulling it in
20150827 22:36:59 <Eclesia> ask you if have questions, documentation is ... sparse ^^
20150827 22:38:52 <xranby_> Eclesia: my main questionwould be how to conenct Graph as the nurbs renderer for your API
20150827 22:40:02 <xranby_> Eclesia: i like the animation work you do a lot, and i would like to experiment having your animators to animate large amounts of data in realtime
20150827 22:40:52 <sgothel> JOGL-Core https://jogamp.org/bugzilla/show_bug.cgi?id=1206; NEWT: https://jogamp.org/bugzilla/show_bug.cgi?id=1205
20150827 22:40:58 <Eclesia> hold your horses, it's draft work, worked and started thinking about it only for a few days :)
20150827 22:41:18 <xranby_> Eclesia: thinking about it for user interfaces and chart plotting already :)
20150827 22:41:49 <Eclesia> (and 3d : the builder works for N dimension spaces)
20150827 22:42:20 <sgothel> an Animator impl. shall work w/ shader ofc .. sure, its a design idea .. and I like it
20150827 22:43:10 <sgothel> IMHO .. having display callbacks .. allowing reading out the current values -> shader/whatever .. render, done -> continue
20150827 22:43:24 <sgothel> hooking in GLEventListener .. sorta
20150827 22:43:51 <sgothel> GLKeyframeListener :)
20150827 22:44:40 <sgothel> @Xerxes: processing bug # ?
20150827 22:45:12 <Eclesia> not exactly the way I made it. I have an Updater interface, there are lists of those on my scene nodes. and there is an AnimationUpdater which makes the link between the apis.
20150827 22:45:55 <Eclesia> updater are called on each gl event with the time.
20150827 22:45:57 <sgothel> sounds similar .. ofc no need to have it 1:1 .. in the end we have diff APIs
20150827 22:46:04 <sgothel> yeah .. similar then :)
20150827 22:47:36 <sgothel> i.e. having additional NodeManipulators in the Animator animating a SG node (transforms .. etc) - if having a SG
20150827 22:49:11 <Eclesia> well it's getting really late, an still have to go to work tomorrow morning
20150827 22:49:15 <Eclesia> good night ++
20150827 22:49:20 <sgothel> good night!
20150827 22:49:31 * Eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20150827 22:49:32 <xranby_> Eclesia: good night
20150827 22:49:45 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=1104 .. is solved right?
20150827 22:50:29 <sgothel> via commit 1eea4278f1be5900f0d990d0a7d352923def217c
20150827 22:51:50 <xranby_> yes likely solved
20150827 22:52:52 <xranby_> i do not know which 2.4.x version you tested with
20150827 22:52:52 <xranby_> but i would mark it as fixed
20150827 22:58:28 <sgothel> yup .. done
20150827 23:00:41 <xranby_> i have an old branch from 2012.. adding compatibility with an old version of libav https://github.com/sgothel/jogl/compare/master...xranby:avformat-F17
20150827 23:00:59 <xranby_> i wonder if someone still uses fedora 17
20150827 23:01:38 <xranby_> i asked one user to test the patch but i never recived any feedback
20150827 23:03:34 <xranby_> the goal of this patch is to make it compatible with a version that did not have sp_avformat_open_input
20150827 23:10:45 <sgothel> https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.3.2#Bugs_to_fix_for_this_release_w.2F_low_effort_.28root_causes_clearly_identified.2C_reporter_available.29
20150827 23:11:00 <sgothel> .. ok .. more work to do, got me employed :)
20150827 23:13:42 <xranby_> i am still trying to find andreas bugreport
20150827 23:14:25 <sgothel> yup .. please make it depend on Bug 1206 .. and change some wording ..
20150827 23:14:32 <sgothel> i.e. it shall be pluggable to this feature
20150827 23:14:39 <sgothel> then add it to 2.3.2
20150827 23:15:11 <sgothel> critical in Bug 1206 is the 'exposure' criteria, i.e. when is it needed.
20150827 23:15:28 <sgothel> doing it for every FBO is surely not so great .. well ..
20150827 23:15:58 <sgothel> and depend it on Bug 1205 .. NEWT is easier .. (onscreen)
20150827 23:16:54 <sgothel> at least .. we can add the *clear* of FBO for known visible entities like GLJPanel and OSX/CALayer
20150827 23:17:01 <sgothel> yup .. adding it to Bug 1206
20150827 23:51:34 * xranby_ (~sabayonus@anon) Quit (Remote host closed the connection)
20150827 23:52:06 * xranby_ (~sabayonus@anon) has joined #jogamp
20150828 00:13:32 <xranby_> found it https://jogamp.org/bugzilla/show_bug.cgi?id=649
20150828 00:13:49 <sgothel> a 3 digit one .. :)
20150828 00:15:32 <xranby_> yes i also found https://jogamp.org/bugzilla/show_bug.cgi?id=145
20150828 00:18:50 <sgothel> we didn't loose any history .. yeah :)
20150828 00:32:02 <xranby_> ok i have added all FBObject and old jogl 1 bugs to depend on 1206 and all newt related to depend on 1205
20150828 00:32:08 <xranby_> good night, sleep well
20150828 00:32:27 <sgothel> good night!
20150828 00:32:43 * xranby_ (~sabayonus@anon) has left #jogamp
20150828 00:46:00 * rmk0_ (~rmk0@anon) has joined #jogamp
20150828 00:47:41 * rmk0 (~rmk0@anon) Quit (Ping timeout: 250 seconds)
20150828 02:52:44 <a11mad11_> is the method create(...) from ShaderCode class look in jar package or in folder?
20150828 05:05:31 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20150828050531.html