JogAmp IRC Chat Logs

#jogamp @ irc.freenode.net - 20150716 14:51:23 (UTC)

20150716 14:51:29 * jogamp (~jogamp@anon) has joined #jogamp
20150716 14:51:29 * Topic is 'http://jogamp.org | Hacking 3D Graphics, Multimedia and Processing across Devices | logs: http://jogamp.org/log/irc/?C=M;O=D'
20150716 14:51:29 * Set by rmk0 on 20141110 16:19:10
20150716 14:51:29 -NickServ- You are now identified for jogamp.
20150716 15:15:18 * elect (~elect@anon) Quit (Ping timeout: 244 seconds)
20150716 15:52:55 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150716 16:04:16 * eclesia (~husky@anon) has left #jogamp
20150716 16:13:13 * doev (~doev@anon) Quit (Ping timeout: 246 seconds)
20150716 17:09:37 * monsieur_max (~maxime@anon) has joined #jogamp
20150716 17:28:59 * jvanek (jvanek@anon) Quit (Quit: Leaving)
20150716 18:25:46 * gouessej (52794da3@anon) has joined #jogamp
20150716 18:26:10 <gouessej> The API documentation of JogAmp's Ardor3D Continuation is available online: http://jogamp.org/deployment/ardor3d/javadoc/
20150716 18:26:24 * gouessej (52794da3@anon) Quit (Client Quit)
20150716 18:47:55 * sgothel (~sgothel@anon) has joined #jogamp
20150716 18:47:55 * sgothel (~sgothel@anon) Quit (Changing host)
20150716 18:47:55 * sgothel (~sgothel@anon) has joined #jogamp
20150716 18:47:55 * ChanServ sets mode +v sgothel
20150716 18:48:40 <sgothel> http://forum.jogamp.org/RC-Test-Build-2-3-2-rc-20150716-td4034915.html .. and hello again. Continuing w/ my janitor job :)
20150716 19:04:02 * elect (~elect@anon) has joined #jogamp
20150716 19:25:21 <elect> I tried to run test.log
20150716 19:25:34 <elect> but I got this
20150716 19:25:36 <elect> java version "1.8.0_45"
20150716 19:25:36 <elect> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
20150716 19:25:36 <elect> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
20150716 19:25:36 <elect> LIBXCB_ALLOW_SLOPPY_LOCK:
20150716 19:25:37 <elect> LIBGL_DRIVERS_PATH:
20150716 19:25:39 <elect> LIBGL_DEBUG:
20150716 19:25:41 <elect> java
20150716 19:25:43 <elect> Error: Could not find or load main class com.jogamp.newt.opengl.GLWindow
20150716 19:26:16 <sgothel> phew .. w/ latest rc ?
20150716 19:27:09 <elect> rc?
20150716 19:27:41 <sgothel> test build, release candidate (RC) .. see above
20150716 19:27:46 <elect> ah
20150716 19:27:52 <elect> no, 2.3.1
20150716 19:28:07 <elect> wait, im not sure
20150716 19:28:16 <elect> how can I check from the jogamp-all-platforms?
20150716 19:28:28 <sgothel> 2151 wget http://jogamp.org/deployment/archive/master/gluegen_868-joal_596-jogl_1401-jocl_1057/archive/jogamp-all-platforms.7z
20150716 19:28:28 <sgothel> 2152 7z x jogamp-all-platforms.7z
20150716 19:28:28 <sgothel> 2153 cd jogamp-all-platforms
20150716 19:28:28 <sgothel> 2154 ls
20150716 19:28:28 <sgothel> 2155 sh ./etc/test.sh
20150716 19:28:32 <sgothel> ^^ worked ..
20150716 19:29:20 <elect> anyway
20150716 19:29:30 <elect> I just wanted to generate it for the bindless bug
20150716 19:29:43 <sgothel> same w/ 2.3.1 on GNU/Linux 64bit .. java8
20150716 19:29:46 <elect> https://jogamp.org/bugzilla/show_bug.cgi?id=1167
20150716 19:30:04 <elect> I do be on Ubuntu x64 java8
20150716 19:30:23 <sgothel> me on Debian 8 Jessie
20150716 19:30:51 <sgothel> only one remote test machine uses Ubuntu 14 LTS
20150716 19:31:10 <sgothel> Bug 1167 .. pls provide a small self containing test case
20150716 19:31:32 <sgothel> AFAIK .. or better - I thought - you wanted to add one stateless unit test anyways ?
20150716 19:32:11 <sgothel> my guess: maybe something to do w/ querying the buffer address. do you do this only once (proper) - or at display (causing sync) ?
20150716 19:32:49 <sgothel> best: use gl mmap to make something persistent .. hmm. but I am not that familiar w/ that NV extension
20150716 19:33:33 <sgothel> also: your perf. tests I read about - would be nice to have it incorporated somewhere .. w/o too much tool-dependencies
20150716 19:33:39 <elect> only once, in the init()
20150716 19:33:54 <elect> the program is already pretty small
20150716 19:34:04 <elect> you can clone it and use it as test case
20150716 19:34:25 <sgothel> assuming you use NEWT .. well, only v-sync and/or a different onscreen pixelformat comes to mind
20150716 19:34:34 <elect> v-sync is off
20150716 19:34:39 <elect> from the nvidia panel
20150716 19:35:01 <sgothel> pls provide a git pull request - for the standalone version: thx! (you know this)
20150716 20:05:53 <elect> why dont we integrate some utility for the shaders?
20150716 20:06:16 <elect> anyway, I am trying to profile the app
20150716 20:06:29 <elect> what is the sun.awt.X11.XToolkit ?
20150716 20:30:59 * elect (~elect@anon) Quit (Ping timeout: 244 seconds)
20150716 20:52:44 <sgothel> ^^ JOGL already has plenty shader utils (loading, uniform/attribute handling etc)
20150716 21:38:11 * xranby_ (~familjen@anon) has joined #jogamp
20150716 21:39:02 <xranby_> good 2.3.2-rc testing evening
20150716 21:40:04 <sgothel> sweet & thx .. good find: the bug 1166 type mismatch on stack ..
20150716 21:40:52 <xranby_> thank you for going the extra mile and polish it further
20150716 21:41:21 <sgothel> the native JNI method NewDirectByteBuffer(..) does take a long value for capacity, so I hope its impl. handles the MAX_INT limitation properly :)
20150716 21:41:50 <sgothel> when things like this happen .. I tend to become paranoid :)
20150716 21:42:53 <sgothel> btw .. do we have a GNU/Linux ARM system _stable_ yet w/ free-software GL driver ? BCM ready yet?
20150716 21:43:34 <sgothel> one day .. we shall hook ARM 32 + 64 bit machines
20150716 21:43:38 <sgothel> (testing)
20150716 21:43:52 <xranby_> the free software driver is not stable yet... the gpu crashes easily when you move xorg windows
20150716 21:44:17 <sgothel> hmm .. ARM + [intel | amd] would be nice ..
20150716 21:44:47 <xranby_> the opengl implementation looks stable, as long as I as an user do not move windows around then i can run quite comples OpenGL 2 applications using the VC4 Mesa3D driver
20150716 21:44:54 <xranby_> complex
20150716 21:45:29 <xranby_> right now i am polishing jogamp in combination with the properitary raspberry pi driver
20150716 21:46:35 <xranby_> there is some strange misalignments of the mousepointer and the windows using our newt native bcm_vc_iv implementation
20150716 21:46:58 <sgothel> oh .. right, I remember a forum post of yours
20150716 21:47:22 <sgothel> maybe the pointer origin is simply wrong ?
20150716 21:47:36 <sgothel> dunno though ..
20150716 21:48:24 <xranby_> i looked through the source of the implementation,, the fist thing that looks odd is that we displace the placement of the pointer icon with the hot zone
20150716 21:48:44 <xranby_> i would have imagined that the hot zone is only used when we calculate the mouse events
20150716 21:49:03 <sgothel> err .. which file ? :)
20150716 21:49:31 <xranby_> jogl/src/newt/native/bcm_vc_iv.c
20150716 21:49:45 <xranby_> inside MovePointerIcon0
20150716 21:51:37 <sgothel> well .. the new coordinate is for the hot-zone (origin)
20150716 21:51:53 <sgothel> crosshair -> w/2, h/2
20150716 21:51:57 <sgothel> (e.g.)
20150716 21:52:52 <sgothel> however .. sure, maybe I got the bcm specs wrong somewhere (must be)
20150716 21:53:23 <xranby_> i will scrutinize it for sure
20150716 21:53:30 <xranby_> and report when i find something
20150716 21:54:05 <sgothel> bcm_moveTo is also used for 'window' (layer) movement .. hmm
20150716 21:54:20 <xranby_> i have found a nice TFT screen that you attach to the raspberry pi GPIO pins, that work with hardware acceleration
20150716 21:55:00 <xranby_> in combination with broadcoms properitary opengl es 2 driver
20150716 21:55:55 <xranby_> the setup is interesting for workrelated stuff, we have a 3d printer ingoing to create a prototype casing for it
20150716 21:56:27 <sgothel> sounds rather expensive .. i.e. why not use display-port via usb (standard interfacing) - or is the GPIO running a similar protocol?
20150716 21:58:41 <xranby_> by attaching the display to the GPIO allows the pi to update the TFT without additional logic chips, you have a total powerconsumption of 4W when the system is on including the TFT
20150716 21:59:04 <sgothel> 'dst_rect.y = p->element.y - p->hotY;' <- or have I simply swapped the vertical orientation ?
20150716 21:59:39 <sgothel> imho .. a bug could be in the setup: Java_jogamp_newt_driver_bcm_vc_iv_DisplayDriver_SetPointerIcon0
20150716 22:00:16 <xranby_> sgothel: the mouse pointer is misaligned in both x and y. when i move the pointer towards upper top left it goes outside the screen
20150716 22:00:38 <sgothel> so the hot (origin) is OK
20150716 22:01:33 <sgothel> maybe the lack of clipping simply causes the issue: (0,0) - (hotX, hotY) ? does it also happen w/ a pointer w/ hot=(0,0) ?
20150716 22:02:12 <xranby_> i have recompiled this file with #define VERBOSE_ON 1
20150716 22:02:21 <sgothel> what happens when moving the window outside of the screen (.. partially) .. AFAIK clipping works .. hmm
20150716 22:02:54 <xranby_> the mousepointer show very interesting visual effects when the pointer is outside the screen
20150716 22:03:14 <xranby_> its trippy, thus clipping do not work
20150716 22:03:20 <sgothel> so it might be the clipping and involved alpha-blending ...
20150716 22:05:16 <sgothel> DISPMANX_FLAGS_ALPHA_FROM_SOURCE <- maybe fiddle w/ that one .. or another mode for layer. hmm. but pointer/layer clipping should work, otherwise it would be quite hard to workaround that
20150716 22:08:03 * rmk0_ (~rmk0@anon) has joined #jogamp
20150716 22:09:53 * rmk0 (~rmk0@anon) Quit (Ping timeout: 252 seconds)
20150716 22:10:12 <xranby_> sgothel: the mousepointer do place itself nicely in the upper left corner when initialized to 0,0 thus that part is correct
20150716 22:10:23 <xranby_> the clipping is one issue
20150716 22:10:34 <sgothel> hot[XY] - check :)
20150716 22:10:46 <sgothel> so clipping/blending .. oh dear :0
20150716 22:11:06 <xranby_> my daugther said, why fix something that looks beautiful?
20150716 22:11:21 <sgothel> haha :) - I used layer = 2000 .. don't remember, maybe a magic layer ?
20150716 22:11:50 <xranby_> the window on the other hand is not aligned with the top left corner
20150716 22:11:58 <xranby_> it has some strange offset
20150716 22:13:19 <xranby_> right the trippy clipping effects appear when the mousepointer is moved into negative clipping regions -64/-64
20150716 22:13:36 <xranby_> issue 1
20150716 22:13:50 <xranby_> issue 2 the mousepointer cant be moved to the bottom right
20150716 22:14:27 <sgothel> bcm_vc_iv.h has some *CLAMP* values .. hmm
20150716 22:14:50 <sgothel> but no clipping .. hmm
20150716 22:15:40 <sgothel> maybe there is a way how to config a layer w/ 'overscan' .. ?
20150716 22:15:43 <xranby_> you stop at 735/415 my display is a 800/480
20150716 22:15:57 <xranby_> thus i cant reach the lover 64x64 pixels
20150716 22:16:56 <sgothel> 64x64 pointer ? w/ hot 0/0 ? who does the limitation ? hmm
20150716 22:18:52 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150716 22:22:22 <xranby_> sgothel: i am runnign with /boot/config.txt disable_overscan=1
20150716 22:22:49 <sgothel> hmm
20150716 22:23:05 <xranby_> the reaspberry pi console fills the entire 800x480 display and i tis also using dispmanx
20150716 22:23:36 <sgothel> the bcm should be setup to tolerate a certain overscan .. would need to know the behavioral specs here ..
20150716 22:24:08 <xranby_> experimenting with the /opt/vc/src/hello_pi/hello_triangle examples
20150716 22:24:13 <xranby_> and they all fill the screen
20150716 22:24:54 <sgothel> then add a layer .. and move it out of the screen a bit .. etc
20150716 22:26:13 <sgothel> i.e. 'overscan seam' - or - implicit clipping to screen-size should remove such artifacts ofc
20150716 22:26:21 <sgothel> usually all those GPU can handle it
20150716 22:26:48 <sgothel> or we need explicit clipping .. as mentioned
20150716 22:37:50 <xranby_> hmm, i notice that we use vc_dispmanx_update_start( 0 ); while the examples on the pi uses vc_dispmanx_update_start( 10 ); the number is a priority value, i have to experiment
20150716 22:40:22 <xranby_> vc_dispmanx_update_start <- this function can fail!
20150716 22:40:38 <xranby_> we should add some if (!current_update)
20150716 22:41:50 <xranby_> i mean we must check if the returned dispman_update != 0
20150716 22:44:33 <xranby_> i will check.. does it fail
20150716 22:44:35 <xranby_> ?
20150716 22:58:23 <xranby_> nope.. added the extra checks. vc_dispmanx_update_start did not fail on us
20150716 23:00:07 <xranby_> BCM.Display Window.Create.0 0x10000000, 64/64 1920x1080, opaque 0, alphaBits 1, layer 0
20150716 23:00:39 <xranby_> i need to have a chat with the caller of this function.. why does the caller pass x=64 & y=64 ?
20150716 23:01:29 <xranby_> that would explain the offset of the window
20150716 23:02:09 <sgothel> :) .. window decoration ? (sure not .. kidding)(
20150716 23:09:49 <xranby_> bcm/vc/iv/WindowDriver.java extends WindowImpl and uses getX() and getY()
20150716 23:10:04 <sgothel> oh .. the default position .. :-/
20150716 23:10:21 <sgothel> yup .. guess we should override that one here, ahem
20150716 23:10:30 <xranby_> nothing wrong with a default possition, as long as the mousepointer is aligned
20150716 23:10:45 <xranby_> bit on the pi.. the default possition may be 0 0
20150716 23:10:54 <xranby_> be set to 0 0
20150716 23:11:11 <sgothel> nah .. I mean the window pos causes the window to exceed the screen resolution
20150716 23:11:54 <sgothel> well .. and yes, the layer position must be taken into account for pointer position as well .. right
20150716 23:12:13 <sgothel> first was for artifact / second for the bottom-right unreachable ..
20150716 23:12:38 <sgothel> good one - guess at least one down ..
20150716 23:13:09 <xranby_> yes one down.. the window is now aligned in top left corner :)
20150716 23:13:21 <sgothel> artifact: window and pointer are out-of-bounds .. maybe thats what causing some trouble
20150716 23:14:26 <sgothel> the 'default' position thingy: 64x64 for window decoration default - i.e. NEWT window pos/size are net w/o deco.
20150716 23:15:01 <xranby_> sgothel: indeed, clipping works ok as long as the pointer is outside the screen but inside the "outside" 64x64 pixels bounds
20150716 23:15:03 <sgothel> hence the NEWT bcm code shall adjust the position for 'fullscreen'
20150716 23:15:28 <sgothel> sweet
20150716 23:16:04 <sgothel> i.e. bcm: if window-size >= screen-size: adjust size (-> screen-size) + position (-> 0/0)
20150716 23:16:29 <sgothel> (all in the java bcm window code ..)
20150716 23:21:29 <xranby_> when i move the pointer outside the screen (it is all hidden) to -15/-23 no clipping distortion is seen if i move one pixel further left or up then i start to see clipping errors
20150716 23:21:59 <sgothel> hmm .. you have the bcm specs ?
20150716 23:22:22 <sgothel> or .. read how the new xorg driver does it ? :)
20150716 23:22:56 <xranby_> the new xorg driver do not use dispmanx at all
20150716 23:23:24 <sgothel> sure .. but the layer model is based on the hardware AFAIK
20150716 23:23:38 <sgothel> so is the artifact / clipping etc
20150716 23:24:04 <xranby_> eric anholt surely has the bcm specs
20150716 23:24:06 <xranby_> hmm
20150716 23:24:31 <sgothel> sure .. a dispmanx or matching hardware spec would be nice here ..
20150716 23:24:39 <sgothel> i.e. magic layer .. clipping etc
20150716 23:25:52 <sgothel> or pointer size is 30x30 max, w/ hot[XY] in the middle :)
20150716 23:26:18 <xranby_> the pointer is 16x24
20150716 23:26:56 <sgothel> w/ hot[XY] at one extreme .. right
20150716 23:27:19 <xranby_> you changed it from 64x64 to 16x24 in bug 676: use proper pointer icon images
20150716 23:27:57 <xranby_> wiht hot 0 0
20150716 23:29:13 <sgothel> maybe: DISPMANX_ELEMENT_CHANGE_DEST_RECT
20150716 23:29:15 <sgothel> ?
20150716 23:29:28 <sgothel> i.e. layer has the notion of source and destination rect
20150716 23:29:46 <sgothel> assuming the delta is clipped (dest <= source) ..
20150716 23:31:00 <sgothel> bcm_moveTo uses that flag ..
20150716 23:31:10 <xranby_> if the pointer is 16x24 why do we allow it to go to -64/-64 ?
20150716 23:31:36 <sgothel> maybe simply 'cut-off' the width/height in there ?
20150716 23:32:26 <xranby_> since the hot zone is at 0 0 i would have expected the pointer to stop at 0/0
20150716 23:32:48 <sgothel> ^^ good question .. hmm, but NEWT does not clamp the mouse pointer ? our mouse input should do that ?
20150716 23:32:52 <xranby_> and possibly be allowed to go past the lower right bottom corner
20150716 23:33:29 <sgothel> usually we get validated coords .. so our mouse input shall clamp it to screen size <- missing code maybe
20150716 23:34:01 <xranby_> i will check the raspberry pi specific LimuxMouseTracker code
20150716 23:34:14 <xranby_> Linux
20150716 23:35:03 <sgothel> in such case .. our bcm Screen impl. shall clamp the values, i.e. event travels through display -> screen -> window then ..
20150716 23:36:12 <sgothel> forget that .. too later :) / simply cut-off value in bcm window :)
20150716 23:36:26 <sgothel> setPointerIconImpl
20150716 23:36:51 <sgothel> linuxMouseTracker <- should get a feature: clamp / bounds .. probably
20150716 23:37:22 <xranby_> LinuxMouseTracker clamps below 0
20150716 23:37:35 <xranby_> thus its not that code that allows -64
20150716 23:37:57 <sgothel> ^^ default position - you set it to zero in the window java impl ?
20150716 23:38:35 <xranby_> ... doh
20150716 23:38:57 <xranby_> no i did a hack and forced it to 0 0 in the native code
20150716 23:39:28 <sgothel> LinuxMouseTracker still needs to clamp at screen size as well
20150716 23:40:01 <sgothel> i.e. wx and wy should be clamped to 0/0 - screen-size
20150716 23:40:10 <sgothel> since the window-pos gets in .. etc etc
20150716 23:40:49 <sgothel> hmm
20150716 23:43:03 <sgothel> nope: the x, y values needs to be clamped to the screen .. hmm. otherwise subsequent moving will move the position (inner state) further away .. etc
20150716 23:43:20 <sgothel> this assumes a 'one screen' setup though .. quite ugly ..
20150716 23:43:30 <xranby_> i am a bit concerned how do users do relative mouse movements in games if the os/frameworks always clamps?
20150716 23:43:42 <sgothel> hence an option for clamping in LinuxMouseTracker would be nice
20150716 23:44:10 <sgothel> well .. here on X/KDE .. the mouse stops moving on the screen border :)
20150716 23:44:11 <xranby_> do we generate events that include the relative mousemovements in case we hit a clamp wall?
20150716 23:44:26 <sgothel> for games .. we do re-pos the mouse .. invisible etc ..
20150716 23:44:38 <sgothel> no wall event
20150716 23:44:46 <sgothel> bit a window enter/exit
20150716 23:44:52 <sgothel> but
20150716 23:46:06 <sgothel> [1] hence optional clamping of the position state (x, y) in the LinuxMouseTracker - used by bcm to clamp to screen size
20150716 23:46:44 <sgothel> [2] our native bcm moveTo code shall reduce the dest-rect to avoid further artifacts (explicit clipping)
20150716 23:47:03 <xranby_> hmm x has private access in WindowImpl tried to do x = 0 in the constructor
20150716 23:47:13 <sgothel> [3] our java bcm window code shall validate pos and size to not exceed screen size
20150716 23:47:38 <sgothel> there is a setter .. (show call tree)
20150716 23:49:06 <sgothel> definePosition
20150716 23:49:24 <sgothel> defineSize
20150716 23:50:19 <sgothel> so all should be set - just [2] has to be seen whether it works ..
20150716 23:52:45 <sgothel> display.moveActivePointerIcon(..) call shall pass the screen coordinates .. hence sum-up the window position (again) ? :)
20150716 23:55:54 <xranby_> yes it work!
20150716 23:56:10 <xranby_> the mousepointer and screen is aligned
20150716 23:56:23 <xranby_> and i can move to the lower right corner
20150716 23:56:41 <xranby_> and i cant move outside the screen to produce artifacts
20150716 23:56:55 <sgothel> now you should be able to move even further out .. and it will take a while until you come back :)
20150716 23:57:02 <sgothel> hence [1] ..
20150716 23:57:32 <xranby_> i would have expected that but
20150716 23:57:48 <xranby_> for some reason the jgoamp code clamps to 799/479
20150716 23:57:53 <xranby_> already!
20150716 23:58:19 <xranby_> and this is correct for my 800x480 display
20150716 23:59:06 <xranby_> lets see.. i will commit this work i have now...
20150716 23:59:13 <xranby_> since it solves my issues
20150716 23:59:31 <sgothel> oh .. well, nice :)
20150717 00:00:04 <sgothel> and no more artifact either .. moving part of the mouse pointer out of bounds?
20150717 00:04:07 <xranby_> no artifacts seen when i move and hide the mousepointer partially outside the screen at the lower right corner
20150717 00:04:35 <xranby_> it is now impossible for me to hide it at the upper left corner, it clamps properly
20150717 00:04:38 <sgothel> sweet .. so your patch simply impl. [3]
20150717 00:05:04 <xranby_> the patch is simply definePosition(0, 0); in bcm/vc/iv/WindowDriver
20150717 00:05:30 <sgothel> I will recommend to impl. [3] in the reconfigure method .. so it fixes all cases
20150717 00:05:49 <xranby_> yes, it is good to fix the cases when the possition is not 0 0
20150717 00:06:04 <sgothel> .. size exceeds .. etc
20150717 00:06:17 <xranby_> but i am a bit fan of pushing commits when you solve your main issue
20150717 00:06:21 <xranby_> big fan
20150717 00:06:44 <sgothel> well .. I would say it is incomplete .. since we already know where it will fail next :)
20150717 00:06:58 <sgothel> but root cause exposed - great
20150717 00:14:38 <xranby_> https://github.com/xranby/jogl/commit/ee5171af3978702e442db4e7592c41ea8e5f7efa
20150717 00:17:47 <sgothel> I prefer to apply a proper fix for other use cases as well. Let us earmark this .. I may add the fix later myself, if you don't push it. Good stuff analyzing the issue.
20150717 00:19:56 <xranby_> i will push a quick update on the forum thread that there exist a workaround for some usecases and point to this discussion
20150717 00:30:01 <xranby_> ok.. done with the news update.. brewing myself a cup of strong tea
20150717 00:31:51 * juank_prada (~juank_pra@anon) Quit (Read error: Connection reset by peer)
20150717 00:33:28 <xranby_> yes earmark! -> bugreport
20150717 00:40:56 <xranby_> sgothel: can we add newt as a component in bugzilla?
20150717 00:41:12 <xranby_> or shall i use embedded?
20150717 00:43:02 <xranby_> i will pick embedded
20150717 00:44:07 <sgothel> NEWT is already there IMHO
20150717 00:45:52 <xranby_> strange, i cant find it when filing a bugreport for jogl :/
20150717 00:55:43 <xranby_> https://jogamp.org/bugzilla/show_bug.cgi?id=1176
20150717 01:19:38 <xranby_> sgothel: thank you again for todays progress
20150717 01:20:25 <xranby_> good night all
20150717 01:20:36 <sgothel> good night
20150717 01:26:41 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=1176#c1 <- pls verify ..
20150717 01:26:49 <sgothel> changes pushed ..
20150717 01:31:09 <sgothel> Oh .. bugzilla: it is 'Product: NEWT'
20150717 01:31:20 <sgothel> right .. all a bit confusing ..
20150717 01:31:31 <sgothel> Product vs Component ..
20150717 04:54:52 * odin_ (~Odin@anon) Quit (Ping timeout: 258 seconds)
20150717 04:58:30 * odin_ (~Odin@anon) has joined #jogamp
20150717 06:36:29 * elect (~elect@anon) has joined #jogamp
20150717 06:37:27 <elect> hi
20150717 06:57:57 <elect> sgothel, you there?
20150717 07:08:48 <elect> some1 has ever used the jogl shader utility?
20150717 07:11:21 * monsieur_max (~maxime@anon) has joined #jogamp
20150717 07:13:45 * doev (~doev@anon) has joined #jogamp
20150717 07:20:37 <elect> god, jogl does deserve a muuuuuch better wiki
20150717 07:23:00 <elect> you have plenty of utils and there is a lot of people asking how to do things
20150717 07:28:12 <monsieur_max> elect: the universal answer is "look in the test classes"
20150717 07:29:17 <elect> where
20150717 07:29:20 <elect> can you gimme the path
20150717 07:29:56 <elect> coz if I look for ShaderProgram constructor usage I only get 5 classes >.>
20150717 07:30:10 <elect> in JOGL I mean
20150717 07:37:20 <monsieur_max> it's an universal answer, not an accurate one :P
20150717 07:37:28 <elect> you bloody
20150717 07:37:43 <elect> so you dont know where these magic classes are?
20150717 07:41:05 <monsieur_max> :) no, i use almost no jogl utils, only the core opengl bindings
20150717 07:42:16 <elect> you see
20150717 07:42:23 <elect> same as me
20150717 07:42:28 <elect> and this is a shame and a pity
20150717 07:42:44 <monsieur_max> well, it's a choice for me
20150717 07:42:47 <elect> coz shader utils looks pretty nice
20150717 07:43:23 <elect> if there were a better wiki I'd have probabily never started to write one in my own
20150717 07:44:10 <monsieur_max> and then, no fun :(
20150717 07:44:17 <elect> ^^
20150717 07:44:26 <elect> you can focus better on the hot things
20150717 07:45:17 <monsieur_max> yeah true, maybe i'd do it like that from now, but i wanted to learn, the hard way
20150717 07:46:01 <elect> you like it hard, dont you
20150717 07:46:17 <elect> cant blame you
20150717 07:50:11 <monsieur_max> :) yeah, it explains why creating my game take so long, creating the whole tooling and utils and discover new thing that forces to break everything and redo again ...
20150717 08:08:32 * jvanek (jvanek@anon) has joined #jogamp
20150717 08:17:32 * eclesia (~husky@anon) has joined #jogamp
20150717 08:17:52 <eclesia> hi
20150717 08:17:56 <elect> hi
20150717 08:28:12 <bruce-> I also wrote my own shader utils, next to utils for handling render target, vertex buffer and textures
20150717 08:28:41 <bruce-> mostly because of lacking documentation and the feel that jogl does it in a clumsy way
20150717 08:42:33 <sgothel> not to myself: remove one sympathy point from bruce :)
20150717 08:43:37 <elect> sgothel, I see only a problem with the jogl shader utils
20150717 08:43:48 <elect> the suffix must be vp or bvp
20150717 08:43:54 <bruce-> sgothel: aww :)
20150717 08:43:59 <sgothel> right .. we should change that :)
20150717 08:44:13 <sgothel> accepting your patch!
20150717 08:44:15 <elect> my glsl highlight plugin in netbeans needs glsl
20150717 08:44:49 <sgothel> and for next 2.4 release we can even break the API :)
20150717 08:44:50 <elect> I suggest we adopt the official Khronos suffixes
20150717 08:44:53 <elect> + .glsl
20150717 08:45:06 <elect> this means vp becomes .vert.glsl
20150717 08:45:17 <sgothel> as bruce mentioned - should be configurable ..
20150717 08:45:20 <elect> moreover jogl lacks the compute shader
20150717 08:45:51 <elect> https://www.khronos.org/opengles/sdk/tools/Reference-Compiler/
20150717 08:46:09 <elect> when is scheduled the 2.4?
20150717 08:46:11 <sgothel> compute shader: a patch and unit test would be great
20150717 08:46:41 <sgothel> well .. when we break the API .. probably after 2.3.2
20150717 08:46:50 <sgothel> i.e. 2.3.3 may become 2.4
20150717 08:47:09 <elect> we are talking about days, weeks or months?
20150717 08:47:13 <sgothel> 2.3.2 .. some hotfixes ..
20150717 08:47:17 <elect> just to organize
20150717 08:47:29 <sgothel> weeks - month .. depending on 3rd party input as well ofc
20150717 08:52:33 <elect> anyway, we should really expand the wiki about the jogl utilities
20150717 08:52:57 <elect> jogl has plenty of them but nobody knows about but few
20150717 08:53:09 <elect> I can help, sgothel
20150717 08:53:13 <sgothel> api-doc + unit tests being referenced by semantics via a wiki -> I agree
20150717 08:53:22 <sgothel> great!
20150717 08:53:31 <sgothel> do you have an account already ?
20150717 08:53:38 <sgothel> I send you one ..
20150717 08:53:41 <elect> on the wiki?
20150717 08:53:52 <sgothel> yup
20150717 08:53:57 <elect> not yet
20150717 08:54:44 <sgothel> I would like to have it sorted by semantics - and reference the jogl API doc (html) plus unit test (git-blob w/ line)
20150717 08:55:06 <sgothel> the latter might need to use a certain version - since files can change, i.e. not simply HEAD
20150717 08:55:16 * eclesia would like just the dialog mode for newt frames . *kneeling in front of god*
20150717 08:55:52 <sgothel> 'dialog mode' ?
20150717 08:56:02 <eclesia> not displayed in the desktop bar
20150717 08:56:09 <eclesia> for popups etc...
20150717 08:56:19 <sgothel> ah .. we have it in bugzilla .. don't we ?
20150717 08:56:23 <eclesia> yes
20150717 08:56:27 <sgothel> good
20150717 08:56:41 <elect> btw, I saw JME3 forum adopted discourse
20150717 08:56:47 <elect> http://hub.jmonkeyengine.org/top
20150717 08:56:53 <sgothel> we had this discussion ..
20150717 08:57:01 <elect> just saying
20150717 08:57:03 <sgothel> popularity is not an argument here :)
20150717 08:57:14 <elect> it depends
20150717 08:57:31 <sgothel> and I always get upset w/ being forced to allow tons of 3rd party cross-java-script stuff .. etc ..
20150717 08:57:59 <sgothel> so the point stands: pure html based server side forum w/ mailinglist interface - secure if possible
20150717 08:58:34 <sgothel> but .. to make the thing circular - I barely started being productive again .. and this is low prio for me
20150717 08:59:08 <sgothel> however: family happy now - and I can focus on stuff again :)
20150717 08:59:19 <eclesia> \o/
20150717 09:00:50 <elect> honestly, given the conditions I think jogl will never leave nabble and this will damage the jogl community
20150717 09:00:58 <elect> 2 cents from the last of nubs
20150717 09:02:00 <elect> Let me just underline my intent, sgothel, I dont want to do polemics, I want to help jogl community
20150717 09:02:13 <elect> I may be wrong ofc
20150717 09:03:43 <sgothel> we usually are a technocracy here .. i.e. favor the technical best solution
20150717 09:04:11 <elect> btw, how can I create an account on the wiki?
20150717 09:04:13 <sgothel> so a new tool w/ is 'not better' .. well .. so we need to find the better one, Mark already found one tool
20150717 09:05:50 <elect> I would like to use as much as possible all the jogl utilities
20150717 09:06:18 <elect> I can modify all my modern jogl tutorials to fit that
20150717 09:06:28 <sgothel> that would be great
20150717 09:06:42 <sgothel> i.e. and enhance the jogl utils on the way ..
20150717 09:07:36 <elect> I mean, you even have a class for uniformData
20150717 09:08:08 <elect> I thing this is some valuable but hidden
20150717 09:08:41 <sgothel> we have that - but I mean, if something is missing/odd - fix it. sure - add something which seems to be useful for the many
20150717 09:08:56 <sgothel> @elect: email send - pls reset your password - use https for the wiki
20150717 09:10:51 <sgothel> https://jogamp.org/wiki/index.php?title=Jogl_API_Overview&action=edit&redlink=1 <- here you go ..
20150717 09:11:02 <sgothel> https://jogamp.org/wiki/index.php/Main_Page <- referenced here
20150717 09:11:03 <elect> pwd?
20150717 09:11:12 <sgothel> email password reset please :)
20150717 09:11:35 <sgothel> I was being told .. there is something like that .. then please change your password again, thx
20150717 09:12:10 <elect> ok
20150717 09:13:28 <sgothel> maybe just walk through a few (ES2+) unit tests and read the API docs .. then you should get a good coverage over the 'essential utils'
20150717 09:13:48 <sgothel> indeed it is best if somebody else does it .. (the review part)
20150717 09:14:15 <sgothel> (i.e. not me ofc .. since I don't see the trees in the woods)
20150717 09:14:44 <elect> what do you mean by API docs
20150717 09:14:54 <elect> the comment in the code?
20150717 09:15:00 <sgothel> https://jogamp.org/deployment/jogamp-next/javadoc/jogl/javadoc/
20150717 09:15:02 <elect> btw where do I find the unit test?
20150717 09:15:24 <sgothel> http://jogamp.org/git/?p=jogl.git;a=tree;f=src/test;h=6ccb9ee1108c12d74af5216f6713a1d727e0c7c4;hb=HEAD
20150717 09:15:42 <sgothel> (a source zip is also provided ..)
20150717 09:16:10 <sgothel> http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/RedSquareES2.java;h=a0afef87a945a1cba4ac18aba428291cab0a2167;hb=HEAD
20150717 09:16:25 <sgothel> [2] http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/RedSquareES2.java;hb=HEAD
20150717 09:16:32 <elect> thanks
20150717 09:16:42 <sgothel> so the first is ref'ing a version, the latter the latest one
20150717 09:17:01 <sgothel> dunno - probably ref'ing a version, since things could change? or both .. ?
20150717 09:17:36 <sgothel> https://jogamp.org/jogl/doc/NEWT-Overview.html <- here I ref both ..
20150717 09:17:36 <elect> let me get it right
20150717 09:17:56 <sgothel> i.e. the latest HEAD and a specific version
20150717 09:17:59 <elect> writing the wiki I should reference code in the examples you linked me
20150717 09:18:09 <sgothel> the git ref for unit tests only ofc
20150717 09:18:27 <elect> why dont we reference directly github?
20150717 09:18:32 <sgothel> yeah .. my thinking is like creating a map
20150717 09:18:36 <sgothel> a semantic map
20150717 09:18:41 <elect> I can easily highlight the interesting code thorught the link
20150717 09:18:51 <sgothel> i.e. how to load shader code? -> API doc + unit test
20150717 09:19:00 <elect> yes
20150717 09:19:09 <sgothel> we use jogamp links b/c that is the official stuff
20150717 09:19:32 <elect> as you want
20150717 09:19:58 <elect> but better font and the possibility to highlight code makes github much better
20150717 09:19:59 <sgothel> like this from the wiki: [{{SERVER}}/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/jogl/demos/es2/RedSquareES2.java;hb=HEAD
20150717 09:20:10 <elect> look
20150717 09:20:10 <sgothel> so it is even portable ..
20150717 09:20:30 <elect> https://github.com/elect86/modern-jogl-examples/blob/master/modern-jogl-examples/src/tut01/Tut01.java#L94-L96
20150717 09:21:02 <sgothel> we can discuss installing another front-end .. well. however, IMHO it is working ..
20150717 09:21:14 <sgothel> I don't like to use a 3rd party dependency here ..
20150717 09:21:31 <elect> as you want
20150717 09:21:34 <sgothel> but if you like - you can also add a column for github additionally ..
20150717 09:21:46 <sgothel> i.e. one of our goals is to be self contained ..
20150717 09:22:07 <sgothel> reduce dependencies .. simple ..
20150717 09:22:20 <elect> we can do the same {GITHUB}/modern-jogl-examples/blob/master/modern-jogl-examples/src/tut01/Tut01.java#L94-L96
20150717 09:23:17 <sgothel> if you like to ref your examples - pls push it to jogamp's git server as well - I will create an account then
20150717 09:23:25 <elect> it was an example
20150717 09:23:55 <sgothel> maybe I am a control freak :)
20150717 09:24:21 <sgothel> (so you are free to add an additional github ref .. besides jogamp)
20150717 09:24:56 <sgothel> note: github is not free software
20150717 09:25:01 <elect> I knew
20150717 09:25:06 <elect> *know
20150717 09:25:21 <elect> but since you are hosting there jogl
20150717 09:25:32 <elect> I dont this any problem referencing it right now
20150717 09:25:39 <sgothel> well - even I are sometimes using convenience w/ folks :)
20150717 09:25:50 <elect> and using variables we can easily port it one day if we will move
20150717 09:25:54 <sgothel> all good - now back to my other unit tests .. work ..
20150717 09:26:22 <sgothel> (the uris may differ - so pls 1st use jogamp git uris .. then optionally add github if you desire)
20150717 09:26:30 <elect> ok
20150717 09:26:41 <sgothel> thank you very much!
20150717 09:26:49 <elect> np
20150717 09:28:21 <sgothel> btw .. when you port your demos .. you may like to port them directly into jogl's unit tests .. and add a few assertions
20150717 09:28:34 <sgothel> this would guarantee them to be tested all the time
20150717 09:28:50 <sgothel> (read: maintained)
20150717 09:29:21 <elect> I dont know if I should modify all my shaders suffixes to make it work with the current jogl or just wait for the flexible release
20150717 09:29:26 <sgothel> in the future we like to have a test launcher .. for users .. we discussed it here a while ago
20150717 09:29:51 <sgothel> -> patch our code to allow customization of suffixes
20150717 09:30:15 <sgothel> (or I do it later .. sure)
20150717 09:37:33 <elect> how can I path your code? Submitting throught git?
20150717 09:38:45 <elect> because I always had problems compiling JOGL from sources
20150717 09:38:58 <elect> so my local copy has tons of errors and I cant submit
20150717 09:42:27 <sgothel> git sure .. and ofc you need to be able to compile gluegen, jogl, ..
20150717 09:43:09 <sgothel> following the howto compile .. section (gluegen, jogl) should give a clue .. usually works
20150717 09:43:51 <xranby_> elect: sgothel: gitlab is a free software version of github that you can host on your own premises, it is built around ruby
20150717 09:44:14 <xranby_> https://about.gitlab.com/
20150717 09:44:21 <elect> I tried and I spent more than one working day on that, never worked
20150717 09:44:30 <elect> I also use gitlab
20150717 09:44:43 <elect> I have nothing against it
20150717 09:44:56 <xranby_> i have deployed a gitlab server at work and it work quite ok. but i do not know how it stand a security review yet
20150717 09:45:41 <elect> sgothel, when you think you can modify the shaderProgram.java? No pressure, just to know
20150717 09:46:17 <sgothel> hehe .. since you [re]write the demo/test code .. well, tomorrow for you
20150717 09:46:33 <elect> ^^ thansk
20150717 09:46:47 <elect> btw I would need a jar to try it
20150717 09:46:50 <elect> if possible :p
20150717 09:46:56 <xranby_> gitlabs busniess model is to provide a community edition and then charge you a fee for some plugins that are usefull for integration
20150717 09:47:08 <sgothel> then I do recommend to also use the shader code customization .. you will find it ..
20150717 09:47:25 <sgothel> re gitlab: at a later time maybe ..
20150717 09:47:31 <xranby_> for example, the jenkins gitlab integration plugin is only found in the "enterprise edition"
20150717 09:47:44 <sgothel> ha! :)
20150717 09:48:05 <sgothel> a jogamp enterprise edition ?? .. what could I add there and get rich? :)
20150717 09:48:14 <sgothel> (just kidding)
20150717 09:48:33 <sgothel> a CD or a t-shirt maybe :)
20150717 09:48:42 <sgothel> CD -> SDCARD :)
20150717 09:48:44 <elect> I dotn get what you mean, sgothel
20150717 09:48:53 <elect> shall I modify in my own?
20150717 09:49:05 <sgothel> no .. I patch it for you by tomorrow
20150717 09:49:09 <elect> ok
20150717 09:49:39 <sgothel> the shader customization: GLSL version .. etc .. see some shader demo code .. in unit tests ..
20150717 09:49:45 <sgothel> I guess I wrote a section in wiki
20150717 09:50:16 <sgothel> http://jogamp.org/wiki/index.php/How_to_write_cross_GLProfile_compatible_shader_using_JOGL
20150717 09:50:36 <sgothel> http://jogamp.org/wiki/index.php/How_to_write_cross_GLProfile_compatible_shader_using_JOGL#GLSL_Version_.26_Default_Precision_Directive
20150717 09:51:02 <sgothel> ^^ also example how things could get written ..
20150717 09:52:13 <xranby_> sgothel: KUDOS i will test the 1176 fixes asap
20150717 09:53:56 <elect> btw sgothel, regarding the test launcher, it would be nice if jogl will have something like this https://github.com/g-truc/ogl-samples
20150717 09:54:43 <xranby_> we have the large jogl-demos.jar maybe we need a nice gui so that its easy to run all the 200+ demos
20150717 09:54:47 <sgothel> Xerxes and I discussed a launcher a long time ago .. for our unit tests .. (single and all unit tests)
20150717 09:55:03 <sgothel> yes .. maybe for jogl-demos as well, even though I consider those out-of date ..
20150717 09:55:06 <xranby_> a launcher for the unit tests is good as well
20150717 09:55:24 <sgothel> the unit test launcher would be cool, since enables folks to run them on client machines .. and report results
20150717 09:55:38 <sgothel> and/or just have fun w/ a single test :)
20150717 09:59:34 <elect> xranby_, what's the difference between the jogl-demos.jar and the jogl src/test/junit/jogl/demos?
20150717 10:00:56 <sgothel> there was a time before unit testing - we stuffed all demos in jogl-demos
20150717 10:01:07 <sgothel> then we started unit testing .. around jogamp's launch
20150717 10:01:23 <sgothel> now .. jogl-demos are quite .. err .. historic
20150717 10:01:27 <elect> so, it is just legacy stuff?
20150717 10:01:38 <sgothel> for core development .. jogl's unit tests are most important
20150717 10:01:41 <elect> just get rid of them
20150717 10:01:46 <elect> it makes confusion
20150717 10:01:59 <sgothel> hence folks who like to have features .. shall have unit tests to track it .. and ensure it still works
20150717 10:02:05 <elect> or make it clear they are historic
20150717 10:02:15 <elect> so people from outside can have a better overview
20150717 10:02:37 <sgothel> you may add a note in the wiki .. however, the git-log is quite expressive here IMHO :)
20150717 10:03:24 <elect> one of the first result when I google "jogl demos" is your repo
20150717 10:03:33 <elect> you should add a little readme
20150717 10:07:03 <elect> anyway sgothel, it'd be nice if we can create shader program in 2 ways
20150717 10:07:16 <elect> passing a string representing the shader itself
20150717 10:07:30 <elect> passing a String representig the path to the shader
20150717 10:07:33 <sgothel> supported
20150717 10:07:43 <elect> cool
20150717 10:07:59 <elect> brb
20150717 10:26:27 * jk4 (~jk4@anon) Quit (Ping timeout: 265 seconds)
20150717 10:32:53 <xranby> elect: i did a survey of the jogl-demos jar some years ago https://gist.github.com/xranby/5966788 the jogl-demos jar contain jogl ports of the opengl "redbook" demos, a lot of java2d + opengl demos + ported nvidia demos + some demoscene demos such as "angeles" that was showcased during javaone 2008 + misc contributions
20150717 10:34:22 <xranby> the junit tests on the other hand is automatic tests that can be run by our builders and work as documentation how to use the API
20150717 10:36:11 * doev (~doev@anon) Quit (Ping timeout: 256 seconds)
20150717 10:47:37 <elect> nice inventory, xranby
20150717 10:50:54 <xranby> elect: all the ports you have made of modern opengl tutorials to jogl is ok candidates for inclusion into jogl-demos
20150717 10:51:43 <elect> nice, but first it'd be nice switch them to use as much as possible jogl utils
20150717 10:54:13 <sgothel> well .. would be great to have some tech stuff as unit tests, i.e. compute shaders, stateless, .. so we have it tested all time. i.e. jogl-demos code won't get attention while being build other than its compilation. I see .. I repeat myself here .. you guys maybe make some compromise ..
20150717 10:55:29 <elect> for unit tests, I can port this
20150717 10:55:30 <elect> https://github.com/g-truc/ogl-samples
20150717 10:55:37 <elect> what you think?
20150717 10:55:57 <xranby> you also have the https://github.com/elect86/modern-jogl-examples archive :)
20150717 10:56:12 <elect> yes, but I see that more as a tutorial
20150717 10:56:14 <elect> :p
20150717 10:56:18 <xranby> https://github.com/elect86/oglDevTutorials
20150717 10:56:22 <elect> also
20150717 10:56:31 <elect> that's still incomplete btw
20150717 10:57:10 <sgothel> ogl-samples does a coverage about GL functionality w/ unit tests? great
20150717 10:57:55 <sgothel> (at least g-truc posts a GL status regularly ..)
20150717 10:58:18 <xranby> sgothel: i am manually testing https://jogamp.org/bugzilla/show_bug.cgi?id=1176 looks good, my application requested a large screen 1980x768 something and jogl resized it to the maximum of my attached screen correctly -> 800x480
20150717 10:58:29 <elect> sgothel, it seems so
20150717 10:58:45 <xranby> mousepointer is inside the visible constraints
20150717 10:59:09 <xranby> right now it would be good to have the junit launcher :)
20150717 10:59:15 <xranby> to run all the automatic tests
20150717 10:59:28 <sgothel> or one .. w/ passing options .. yes! :)
20150717 10:59:56 <sgothel> then adding an email account to collect results .. and make stats ..
20150717 11:00:08 <sgothel> then w/ ogl-samples included .. holy moly :)
20150717 11:00:43 <xranby> usability on raspbery pi has improved ++
20150717 11:01:00 <elect> wait, I lost you, sgothel
20150717 11:01:04 <elect> >.>
20150717 11:04:02 <xranby> i have identified a new raspberry pi newt issue, if you request a newt screen before initializing opengl you will run into a "symbol lookup error: ../path/to/processing_sketch/libnewt.so: undefined symbol: bcm_host_init"
20150717 11:04:43 <xranby> because, the broadcom library that contains the missing symbol has not been loaded
20150717 11:04:55 <xranby> this is seen if you try to run processing 3 using newt
20150717 11:05:13 <xranby> processing 3 tries to initialize the newt screen before initializing opengl
20150717 11:05:44 <sgothel> hmm .. then we shall move the bcm_*_init to its DisplayDriver ..
20150717 11:06:01 <sgothel> pls make it so .. then its tested :)
20150717 11:06:13 <sgothel> (I just hacked all this 'blindly')
20150717 11:06:31 <xranby> the current implementation do work for OUT api usage :)
20150717 11:06:33 <xranby> OUR
20150717 11:06:46 <xranby> i will hack and test
20150717 11:07:01 <sgothel> great!
20150717 11:22:08 * doev (~doev@anon) has joined #jogamp
20150717 11:23:03 <xranby> we do run bcm_host_init() during DisplayDriver_initIDs... the issue is that we have not loaded the native library hmm
20150717 11:24:27 <xranby> /opt/vc/lib/libbcm_host.so
20150717 11:26:14 <xranby> that file is indirectly loaded when we load the libGLESv2.so
20150717 11:26:23 <xranby> /opt/vc/lib $ ldd libGLESv2.so
20150717 11:26:28 <xranby> libbcm_host.so => /opt/vc/lib/libbcm_host.so (0x76e79000)
20150717 11:27:42 <sgothel> so we need to do this upfront .. hmm
20150717 11:28:05 <sgothel> explicit loading libbcm_host.so .. in Display ..
20150717 11:52:49 <xranby> processing 3 contains this code snippet
20150717 11:52:51 <xranby> protected void initScreen() {
20150717 11:52:51 <xranby> display = NewtFactory.createDisplay(null);
20150717 11:55:26 <xranby> when processing is passing null here it run into an exception Failed to find NEWT display class <.bcm.vc.iv.DisplayDriver> at DisplayImpl:299
20150717 11:55:41 <sgothel> NativeLibrary.open("bcm_host", DisplayDriver.class.getClassLoader(), true); <- within bcm's DisplayDriver static init ..
20150717 11:56:11 <sgothel> ops .. another bug
20150717 11:56:29 <sgothel> or maybe just b/c of the missing native lib ..
20150717 11:56:30 <xranby> ok i will replace my System.loadLibrary("bcm_host"); with NativeLibrary.open("bcm_host", DisplayDriver.class.getClassLoader(), true);
20150717 11:56:33 <sgothel> I guess so ..
20150717 12:02:36 <xranby> ok now it did find the bcm.vc.iv.DisplayDriver -> but it failed later https://gist.github.com/xranby/67ab02b7d18f4ac1483e Caused by: java.lang.UnsupportedOperationException: Method "eglGetDisplay" not available at com.jogamp.opengl.egl.EGL.eglGetDisplay(EGL.java:535)
20150717 12:03:44 <xranby> because we have not yet loaded the broadcom libEGL
20150717 12:03:49 <xranby> i guess
20150717 12:05:13 <sgothel> duh ..
20150717 12:05:23 <sgothel> sorry .. yes, we need JOGL initialized ..
20150717 12:05:33 <sgothel> hence a GLProfile.initSingleton() would be needed ..
20150717 12:06:41 <eclesia> the more I hear the more horrible JNI/OpenGL initialisation looks like.
20150717 12:07:09 <xranby> eclesia: raspberry pi is special, we have to dynamically initialize a properitary api
20150717 12:07:23 <xranby> that is only found on broadcom viceo core iv systems
20150717 12:09:51 <xranby> sgothel: ok that did the trick, it sucessfully initialized the mousepointer,, and initialized opengl es 1 ... i have to fix the processing code to actually request a GL2ES2 profile
20150717 12:21:42 <xranby> https://github.com/xranby/jogl/commit/5667e4320443289a1c0bd02f54bf466bfc2c5895
20150717 12:23:12 * jk4 (~jk4@anon) has joined #jogamp
20150717 12:36:38 <xranby> sgothel: shall i file a bugreport for https://github.com/xranby/jogl/commit/5667e4320443289a1c0bd02f54bf466bfc2c5895 ?
20150717 12:52:09 <xranby> sgothel: https://jogamp.org/bugzilla/show_bug.cgi?id=1177
20150717 12:54:35 <elect> is there any pipeline util in jogl?
20150717 12:54:49 <sgothel> sweet thx .. will merge in a bit
20150717 12:54:59 <sgothel> a Trace and Debug pipeline
20150717 12:55:10 <sgothel> and you can build your own ..
20150717 12:55:34 <sgothel> GLPipelineFactory <- :)
20150717 12:55:54 <xranby> -Djogl.debug.DebugGL -Djogl.debug.TraceGL
20150717 12:56:23 <xranby> very usefull to find the exact location of the opengl call that generated the error
20150717 12:56:25 <sgothel> for the default .. pipelines statically being used .. Above for programatic
20150717 12:56:38 <sgothel> I was thinking about a performance pipeline ..
20150717 12:56:49 <sgothel> time, invocation count ..
20150717 12:57:01 <xranby> using it right now to find where processing is breaking opengl es 2 api by passing some invalid arguments
20150717 12:57:27 <elect> I guess we are not talking about the same pipeline
20150717 12:57:38 <elect> I meant some sceneGraph util
20150717 12:57:48 <sgothel> lol :)
20150717 12:57:51 <xranby> elect: graph!
20150717 12:58:01 <elect> :D
20150717 12:58:26 <sgothel> so OVR works .. now I need to add code for the head-tracker
20150717 13:02:20 <xranby> Oculus VR -- cool!
20150717 13:02:55 <sgothel> well .. I am disappointed that they took away the client renderer mode.
20150717 13:03:15 <xranby> i have the paper VC toy that convert an android phone into a vr device
20150717 13:03:28 <xranby> by strapping the phone in front of your eyes
20150717 13:04:12 <xranby> https://www.google.com/get/cardboard/
20150717 13:04:24 <sgothel> then you can use the generic stereo 'driver'
20150717 13:04:44 <sgothel> hmm .. we only need to have some orientation input ..
20150717 13:05:19 <xranby> this cardboar depend on accelerometer android api input
20150717 13:05:25 <xranby> for headtracking
20150717 13:05:48 <sgothel> I doubt the cardboard depends on anything :)
20150717 13:06:08 <sgothel> but yes, accel./gyro input would help
20150717 13:06:32 <sgothel> then we might need to add custom lens config for generic-device .. to match the hw-config
20150717 13:06:53 <sgothel> if anybody like to add such a setup .. great
20150717 13:07:39 <sgothel> links: StereoDemo01, GenericStereoDeviceFactory
20150717 13:43:22 <elect> what is the SurfaceScale?
20150717 13:43:35 <elect> glWindow
20150717 13:43:50 <elect> api doc doesnt help
20150717 13:44:03 <elect> i need a nub doc
20150717 13:49:44 <xranby> proof of concept processing 3 is running on the raspberry pi 2 using NEWT http://forum.jogamp.org/Processing-P3D-Raspberry-Pi-OpenGL-doesn-t-work-tp4034928p4034929.html
20150717 13:50:35 <xranby> i have some issue with processing animator,,, only the first frame is drawn hmm
20150717 13:58:16 <xranby> the image clearly reveal that it may be good to use the xorg input and window system to provide an X11 window that catches input to prevent the dual mousepointer issue if you try to use jogl's bcm driver inside xorg http://forum.jogamp.org/file/n4034929/Processing_3_runnign_for_the_first_time_using_broadcoms_OpenGL_ES2_driver_and_NEWT_on_the_raspberry_pi.jpg
20150717 13:59:28 <xranby> earmarking -> filing bugreport
20150717 14:05:35 <xranby> https://jogamp.org/bugzilla/show_bug.cgi?id=1178
20150717 14:24:06 * jvanek (jvanek@anon) Quit (Quit: Leaving)
20150717 14:36:52 <xranby> http://labb.zafena.se/jogamp/vc4/video20150717_163245117.mp4 <- the processing 3 RGB cube demo running using newt
20150717 14:46:59 <monsieur_max> neat ! :)
20150717 14:58:13 * rmk0_ is now known as rmk0
20150717 14:58:17 * rmk0 (~rmk0@anon) Quit (Changing host)
20150717 14:58:17 * rmk0 (~rmk0@anon) has joined #jogamp
20150717 14:59:57 <xranby> monsieur_max: i had to force the animator to start.. probably not the right solution but it made the code "work": https://github.com/xranby/processing/commit/f9d170b33bf727d881a0de2e796f9a1e50b5b0b4
20150717 15:00:51 <xranby> processing 3 has some interesting heuristics when to start the animator and so on... likely caused by legacy awt code
20150717 15:01:00 <xranby> that is about to get removed
20150717 15:01:10 <xranby> since processing 3 has moved from using awt -> newt
20150717 15:01:27 <monsieur_max> ah ok :) speaking of this, why should one prefere Animator over FPSAnimator ?
20150717 15:01:52 <xranby> monsieur_max: Animator gives higher perfomance, redraw for each frame
20150717 15:02:02 <xranby> while FPSAnimator is trigegred by a timer
20150717 15:02:23 <xranby> thus you will always get better and more fluid performance using Animator
20150717 15:02:39 <monsieur_max> ok, i like this answer ;) since i'm using animator
20150717 15:03:52 <elect> do you also see enourmous fonts at the end http://jogamp.org/deployment/jogamp-current/javadoc/jogl/javadoc/com/jogamp/opengl/util/glsl/ShaderCode.html#defaultShaderCustomization%28com.jogamp.opengl.GL2ES2,%20boolean,%20boolean%29?
20150717 15:04:01 <xranby> any only use i can see for using fpsanimator is if you use software rendered opengl and want to reduce CPU usage by capping the framerate
20150717 15:04:57 * rmk0 kicks FPSAnimator
20150717 15:05:14 <monsieur_max> fine fine :)
20150717 15:05:24 <monsieur_max> xranby : thaks for your answer
20150717 15:08:04 <xranby> you are welcome
20150717 15:26:06 * elect (~elect@anon) Quit (Ping timeout: 248 seconds)
20150717 15:33:08 * doev (~doev@anon) Quit (Quit: Verlassend)
20150717 15:49:44 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150717 15:54:59 * elect (~elect@anon) has joined #jogamp
20150717 16:07:55 * eclesia (~husky@anon) has left #jogamp
20150717 16:11:33 * elect (~elect@anon) Quit (Ping timeout: 265 seconds)
20150717 16:29:49 * monsieur_max (~maxime@anon) has joined #jogamp
20150717 17:26:20 <xranby_> elect: yes i also see enourmous fonts at the end of the javadoc .. caused by nested relative font size changes in the css
20150717 17:28:23 <xranby_> it apears both font-size:76%; and font-size:1.1em; causes relative font changes
20150717 17:29:34 <sgothel> .. you may fix our javadoc css style .. (I barely hacked it along .. )
20150717 17:48:21 * juank_prada (~juank_pra@anon) has joined #jogamp
20150717 18:19:59 * juank_prada (~juank_pra@anon) Quit (Read error: Connection reset by peer)
20150717 18:20:27 * juank_prada (~juank_pra@anon) has joined #jogamp
20150717 19:49:16 * elect (~elect@anon) has joined #jogamp
20150717 20:05:29 * xranby_ (~familjen@anon) Quit (Ping timeout: 265 seconds)
20150717 20:05:58 * xranby_ (~familjen@anon) has joined #jogamp
20150717 20:06:08 * elect (~elect@anon) Quit (Ping timeout: 244 seconds)
20150717 20:06:34 * elect (~elect@anon) has joined #jogamp
20150717 21:50:50 * elect (~elect@anon) Quit (Ping timeout: 240 seconds)
20150717 22:47:17 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20150718 02:33:35 * Blizzack (185ac594@anon) has joined #jogamp
20150718 02:36:04 * Blizzack (185ac594@anon) has left #jogamp
20150718 04:38:47 * juank_prada (~juank_pra@anon) Quit (Read error: Connection reset by peer)
20150718 05:05:24 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20150718050524.html