#jogamp @ irc.freenode.net - 20130814 05:06:07 (UTC)

20130814 05:06:07 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20130813050607.html
20130814 05:06:07 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20130814050607.html
20130814 09:33:12 * xranby (~xranby@anon) Quit (Ping timeout: 268 seconds)
20130814 09:38:09 * xranby (~xranby@anon) has joined #jogamp
20130814 09:53:33 * xranby (~xranby@anon) Quit (Ping timeout: 268 seconds)
20130814 09:57:33 * xranby (~xranby@anon) has joined #jogamp
20130814 10:40:40 * odin_ (~Odin@anon) Quit (Ping timeout: 260 seconds)
20130814 10:53:26 * odin_ (~Odin@anon) has joined #jogamp
20130814 11:07:19 * xranby (~xranby@anon) Quit (Quit: Leaving.)
20130814 12:17:49 * xranby (~xranby@anon) has joined #jogamp
20130814 12:18:15 <sgothel> good afternoon ..
20130814 12:18:27 <sgothel> hi Xerxes, Mark, .. and all
20130814 12:18:52 <rmk0> lo
20130814 12:19:01 <rmk0> how's it going?
20130814 12:19:49 <sgothel> regarding GLMediaPlayer TODO: the a/v sync (especially determine accurate audio clock for player thread video delay addition (?))
20130814 12:20:04 <sgothel> Mark .. you address for the t-shirt .. L or XL ?
20130814 12:20:19 <sgothel> like to send 'em next week .. collecting address ..
20130814 12:20:30 <sgothel> I guess I have yours from last year .. hmm
20130814 12:21:07 <rmk0> hehe, i think both L and XL will be like wearing a camping tent on me, but i imagine they'll make nice souveniers!
20130814 12:21:19 <sgothel> *Surrey ?
20130814 12:21:25 <rmk0> yep, same address
20130814 12:21:33 <rmk0> i'll take whatever you need to get rid of most urgently :D
20130814 12:21:34 <sgothel> ah great
20130814 12:22:09 <sgothel> took me 3s to process your equation - good morning :)
20130814 12:23:55 <sgothel> your address line .. I see .. what is what ? i.e. I need [street + number], city/place, postal code - maybe you can help me decipher it via email ? :)
20130814 12:24:16 <rmk0> ok, one minute
20130814 12:25:58 <rmk0> sent
20130814 12:36:11 <sgothel> GLMediaPlayer: .. will add the approx. audio delay to the video delay sync .. for testing - but I am afraid that would be it for now .., i.e. sync happing from player thread. Problem: OpenAL does _not_ provide a high-resolution: 'remaining' bytes in buffer (+/- 50ms)
20130814 12:37:10 <sgothel> GLMediaPlayer: Current sync strategy: keep audio flowing .. sleep for audio/video delays in renderer thread
20130814 12:44:43 <xranby> sgothel: how about instead of sleep simply do not rotate images and display the same image?
20130814 12:45:21 <xranby> the frame cycle is lower than a sleep
20130814 12:45:34 <xranby> compared to
20130814 12:45:37 <sgothel> hmm .. yes, also an option good one, will consider when having better control of the audio clock
20130814 12:45:57 <sgothel> repeat last frame == sleep
20130814 12:46:08 <xranby> yup
20130814 12:46:18 <xranby> and i think that is a good solution == non blocking
20130814 12:46:29 <sgothel> not blocking animator .. great for having tons of videos shown on a collection wall :)
20130814 12:46:36 <xranby> exactly
20130814 12:46:44 <xranby> will fix the macosx users usecase
20130814 12:46:58 <sgothel> w/ threaded decoder .. the callback path is possible as well now
20130814 12:47:00 <xranby> who complained about lost frames with many simultanious movies
20130814 12:47:46 <sgothel> would be nice if those users can post better unit tests / later like to add such w/ graph-ui
20130814 12:48:05 <xranby> yes.. but dont we have a multi movie usecase already?
20130814 12:48:17 <xranby> i saw two simultanious movies rendered on the android
20130814 12:48:37 <xranby> maybe extend it to become a testcase
20130814 12:48:45 <xranby> somehow
20130814 12:50:12 <xranby> test == ok if rendering time stay below 16ms
20130814 12:50:27 <xranby> or similar for one frame
20130814 12:50:46 <xranby> with 4 movies
20130814 13:05:14 <sgothel> (back .. ) .. yup, will see
20130814 14:02:17 * xranby (~xranby@anon) Quit (Read error: Operation timed out)
20130814 14:20:33 * xranby (~xranby@anon) has joined #jogamp
20130814 14:53:33 * xranby (~xranby@anon) Quit (Ping timeout: 264 seconds)
20130814 14:57:56 * xranby (~xranby@anon) has joined #jogamp
20130814 15:03:04 * gouessej (546051e4@anon) has joined #jogamp
20130814 15:03:09 <gouessej> hi
20130814 15:03:28 <gouessej> Xerxes, have you seen this bug report? http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1516
20130814 15:04:27 <xranby> yes, i saw the bug, caused by a security update
20130814 15:04:39 <xranby> hence hard to simply rolllback a regression
20130814 15:05:24 <xranby> best is if this is fixed in openjdk upstream
20130814 15:05:29 <xranby> then we may backport something
20130814 15:07:21 <gouessej> Do you have an idea of which change list or security fix caused that bug?
20130814 15:07:45 <xranby> gouessej: before the security update(s) that got pushed out there was a warning that the updatewill break awt applications http://blog.fuseyism.com/index.php/2013/06/19/imminent-icedtea-web-breakage/
20130814 15:08:08 <xranby> here they only focused on icedtea-web because that was one of their own code bases
20130814 15:08:41 <xranby> its possible that the many awt and swing apps needs something like this http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2013-June/023745.html (guess)
20130814 15:09:10 <xranby> apart from that i have no clue
20130814 15:09:32 <gouessej> :(
20130814 15:09:44 <gouessej> ok thanks
20130814 15:09:56 <gouessej> Does it impact OpenJDK 1.7 too?
20130814 15:10:05 <xranby> gouessej: i dont know..
20130814 15:10:15 <xranby> i have not been able to reproduce the bug: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=1516
20130814 15:10:48 <xranby> it looks to hit hard on JOSM users
20130814 15:11:12 <xranby> "One stack trace shows EventQueue.isDispatchThread() returning false from within the dispatch thread." sounds like madness
20130814 15:12:24 <gouessej> yes
20130814 15:12:25 <xranby> https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/1204906 - "All is fine in current OpenJDK 7."
20130814 15:12:31 <gouessej> cool
20130814 15:13:20 <sgothel> re: AWT-EDT troubles - good that this is fixed, hopefully our unit tests will no more claim a 'dead AWT-EDT' :)
20130814 15:13:36 <gouessej> but Andrew's fix only impacts Icedtea-Webstart, doesn't it?
20130814 15:13:57 <xranby> gouessej: yes
20130814 15:14:28 <xranby> The icedtea 1.12.6 may be of use to help find the changeset that caused the issue: http://blog.fuseyism.com/index.php/2013/07/10/security-icedtea-1-11-12-1-12-6-for-openjdk-6-released/
20130814 15:14:36 <xranby> icedtea 1.12.6 release log
20130814 15:14:53 <gouessej> yes I looked at the release note and I suspect a change concerning Netbeans
20130814 15:14:56 <gouessej> a backport
20130814 15:15:39 <xranby> if we can reproduce the bug then its easy to check with and without this backport
20130814 15:16:39 <sgothel> note: firefox 23.0 plugins.click_to_play no more works, i.e. even if set to '1', the plugins start immediately .. hmm
20130814 15:16:49 <xranby> sgothel: :/
20130814 15:17:20 <gouessej> Applets has never worked reliably on my machines under GNU Linux anyway
20130814 15:17:34 <gouessej> "have"
20130814 15:18:14 <sgothel> that is the only reason I still use the proprietary JRE .. so hope I can test w/ our own plugin soon :)
20130814 15:21:32 <gouessej> I hope this bug will get fixed very soon. It doesn't encourage people to use OpenJDK
20130814 15:23:53 <xranby> gouessej: i thought you only encouraged people to use maintained software :) that is enforce people to switch from OpenJDK 6 -> 7
20130814 15:24:32 <sgothel> .. as we test w/ openjdk8 now :)
20130814 15:24:38 <xranby> now that OpenJDK 6 is in enterprise maintaince mode
20130814 15:24:39 <gouessej> yes you're right, it would be a better solution
20130814 15:25:14 <xranby> enterprise maintaince mode == bugs gets fied if you open your pockets and hand out the money
20130814 15:25:26 <xranby> only
20130814 15:25:59 <xranby> personallly i only bring in new jamvm updates to openjdk 6
20130814 15:26:22 <gouessej> I'll switch to OpenJDK 1.7. The pre-beta version of TUER is not yet used by a lot of people, it won't bother Mac users
20130814 15:28:20 <xranby> gouessej: we had quite good success of manual builds of Ji Gong JRT for linux using OpenJDK 8
20130814 15:28:58 <xranby> build instructions pushed to http://jogamp.org/git/?p=jigong.git;a=summary
20130814 15:30:09 <gouessej> :)
20130814 15:32:39 <gouessej> Sven, let me know when you can answer my questions about the bug report 814
20130814 15:32:51 <gouessej> concerning PointerEvent
20130814 15:35:53 <sgothel> PointerEvent may replace the name MouseEvent .. i.e. objective is to have one smart PointerEvent management to reduce API explosion.
20130814 15:36:27 <gouessej> What about the listeners?
20130814 15:36:29 <sgothel> we may need to create a git branch for this to learn as we go .. while not disturbing others .. then switch later on.
20130814 15:36:31 <gouessej> MouseListener
20130814 15:36:36 <sgothel> the whole show!
20130814 15:36:53 <gouessej> yes, good idea, a separate branch
20130814 15:37:49 <gouessej> Should we rename MouseListener whereas it deals with events for mice?
20130814 15:37:57 <sgothel> I can start this branch until .. err Monday, i.e. probably a good day to deal w/ things ..
20130814 15:38:11 <sgothel> the new PointerEvent will deal w/ all 'pointer events' - that is the idea :)
20130814 15:38:22 <sgothel> mice, joystick .. whatever ..
20130814 15:38:50 <sgothel> yes, we need to abstract 'button' in a way that it pleases all those devices, i.e. 'short' ..
20130814 15:38:59 <gouessej> Therefore, there should be a single PointerListener class
20130814 15:39:20 <gouessej> ok but a short is not enough for the use of a gamepad
20130814 15:39:29 <gouessej> short <-> description
20130814 15:39:30 <sgothel> yes .. maybe 'plugins' to it .. we will see. since it is complex .. we will learn as we go, trying to keep it simple ofc
20130814 15:39:55 <sgothel> a description to a devices components may be provided by the device instance
20130814 15:40:14 <sgothel> hence the event will reference the device instance
20130814 15:40:41 <gouessej> good, I suggested something similar in the very first draft
20130814 15:40:44 <sgothel> (just an idea ..)
20130814 15:40:49 <sgothel> sweet
20130814 15:41:07 <gouessej> ok I have to leave. Bye
20130814 15:41:12 <sgothel> laters & bye
20130814 15:41:12 * gouessej (546051e4@anon) Quit (Quit: Page closed)
20130814 18:30:42 * kermyt (~kermyt@anon) Quit (Ping timeout: 264 seconds)
20130814 18:33:26 * kermyt (~kermyt@anon) has joined #jogamp
20130814 19:14:10 * xranby (~xranby@anon) Quit (Ping timeout: 245 seconds)
20130814 19:16:16 * xranby (~xranby@anon) has joined #jogamp
20130814 20:40:09 * Markt_ (32c4d781@anon) has joined #jogamp
20130814 20:40:25 <Markt_> Hello, I was wondering if anyone knew where i can find the code for: GL4bcImpl.java
20130814 20:40:36 <Markt_> it doesn't seem to be in the source tree
20130814 20:40:46 <sgothel> it's generated ..
20130814 20:40:53 <Markt_> I am trying to multi-thread render
20130814 20:41:11 <sgothel> also in the provided source zip file of deployed sets ..
20130814 20:41:12 <Markt_> and it seems that my state machine isn't staying within the context
20130814 20:41:45 <Markt_> gl.glEnableClientState(arrayType);
20130814 20:41:52 <Markt_> gl.glTexCoordPointer(data.getElemSize(), GL.GL_FLOAT, 0, 0L);
20130814 20:42:07 <Markt_> ends up generating error: javax.media.opengl.GLException: array vertex_buffer_object must be enabled to call this method
20130814 20:42:38 <Markt_> Rendering from 2 seperate threads, each with their own gl context and window. is this possible?
20130814 20:47:32 <sgothel> threads won't interfere ..
20130814 20:48:14 <Markt_> 1 ENBALING on 8603#graphic_background_01-mesh_#graphic_background_01_0-UV1
20130814 20:48:14 <sgothel> VBO array must be enabled if passing a VBO offset pointer ..
20130814 20:48:25 <Markt_> BOO: START: 8603#graphic_background_01-mesh_#graphic_background_01_0-UV1
20130814 20:48:27 <sgothel> (not just client state ..)
20130814 20:48:30 <Markt_> javax.media.opengl.GLException: array vertex_buffer_object must be enabled to call this method
20130814 20:48:44 <Markt_> it seems like another thread came and took the enabled client state away
20130814 20:48:58 <Markt_> i have the vbo array enabled 1 line before i actually call it
20130814 20:49:04 <sgothel> that exception is generated by us .. a fail safe
20130814 20:49:26 <sgothel> it is tracked w/ the GLContext instance (thread safe)
20130814 20:50:04 <Markt_> hmm
20130814 20:50:09 <Markt_> i'm not sure how it can be disabled
20130814 20:50:15 <Markt_> in between my calls
20130814 20:50:36 <sgothel> sure you have enabled it in the 1st place (not client-state)
20130814 20:51:15 <Markt_> which call is non client state?
20130814 20:51:23 <Markt_> glEnable(?)
20130814 20:51:23 <Markt_> ?
20130814 20:55:29 <sgothel> glBindBuffer
20130814 20:55:43 <Markt_> gl.glBindBuffer(GL2.GL_ARRAY_BUFFER, cacheHandle.getVboHandle());
20130814 20:55:49 <Markt_> right above that =\
20130814 20:56:39 <sgothel> send a link to your code .. note: your code has not been posted here
20130814 20:57:26 <sgothel> note to myself: change error message 'enabled' -> 'bound' .. duh!
20130814 20:58:35 <Markt_> hehe ya that makes more sense
20130814 20:59:53 <Markt_> http://pastebin.com/gRtCwME8
20130814 21:02:23 <Markt_> according to the prints:
20130814 21:02:23 <Markt_> 24520 = 10 TXPOINTER: 24520 = 10 javax.media.opengl.GLException: array vertex_buffer_object must be enabled to call this method
20130814 21:02:33 <Markt_> there is definitaly a VBO bound
20130814 21:03:14 <Markt_> the crash only happens on Inbetween renders
20130814 21:03:26 <Markt_> when i have a rendering from thread 0 and then at the same time one from thread 1
20130814 21:03:35 <Markt_> on their own, they work perfect every time
20130814 21:03:43 <Markt_> if i turn off one of them, the other is ok
20130814 21:04:54 <sgothel> .. and you use 2 GLContext, one per thread you say ?
20130814 21:05:34 <sgothel> (i.e. we test many-threads, each their ctx .. etc - hence all separated .. good)
20130814 21:05:42 <sgothel> we also test w/ shared GLContext ..
20130814 21:06:30 <sgothel> or do you use 1 GLcontext .. alternately .. from 2 threads ? makeCurrent/release called properly ?
20130814 21:07:04 <sgothel> how about you run your test w/ '-Djogl.debug.DebugGL' ?
20130814 21:17:46 <sgothel> Note: The 'bufferStateTracker' instance is bound to the GL instance, which in turn is bound to the GLContext !
20130814 21:18:08 <sgothel> so if you 'cache' the GL instance (don't do this ever ..) .. you may experience this ..
20130814 21:18:18 <sgothel> i.e. 2 GLContext .. but 1 GL instance
20130814 21:18:25 <sgothel> must be it ..
20130814 21:27:12 <sgothel> re: 'jsr231' .. we are no more bound to the old 'Sun' java JSR ..
20130814 21:28:36 <Markt_> Ya that jsr231 is from the old xith we used
20130814 21:28:44 <Markt_> ya it is shared gl thingy
20130814 21:28:54 <Markt_> we have 2 seperate threads
20130814 21:28:59 <Markt_> 2 windows
20130814 21:29:02 <Markt_> GLWindow
20130814 21:29:26 <sgothel> https://jogamp.org/bugzilla/show_bug.cgi?id=815 <- thx!
20130814 21:29:35 <Markt_> we odn't do make current ourselves, we just use display()
20130814 21:29:38 <Markt_> which i think does it for us
20130814 21:29:42 <sgothel> sure ..
20130814 21:29:51 <sgothel> do you use the given GL instance ?
20130814 21:29:59 <sgothel> .. or do you secretly cache things ?
20130814 21:30:21 <Markt_> we cache our own state
20130814 21:30:39 <Markt_> for most things, though not everything
20130814 21:30:50 <sgothel> the GL instance, i.e. 'gl' !
20130814 21:31:03 <Markt_> we use:
20130814 21:31:31 <sgothel> which refs the bufferStateTracker (see above)
20130814 21:31:48 <Markt_> gl = drawable.getGL().getGL2();
20130814 21:32:13 <Markt_> omg
20130814 21:32:16 <Markt_> //DJG 06-17-2010, SID.01.12 BEGIN CHANGE: Use one GL context for all windows if (gl==null){ gl = drawable.getGL().getGL2(); } else { drawable.setGL(gl);
20130814 21:33:00 <Markt_> ok, nvm
20130814 21:33:02 <sgothel> looks 'fishy' :)
20130814 21:33:08 <Markt_> some dude in 2010 put a static!
20130814 21:33:12 <Markt_> grumbles
20130814 21:33:39 <sgothel> http://jogamp.org/git/?p=jogl.git;a=commit;h=6c72b1fc68e65bc0d4a0ee1e0442cc1637a67d01 *done*
20130814 21:33:57 <sgothel> yeah .. evil public static stuff .. no more works, since we need to track things ..
20130814 21:34:10 <sgothel> not only this case, but for FBO, VAO .. etc
20130814 21:34:31 <Markt_> ya
20130814 21:34:33 <Markt_> geez
20130814 21:34:34 <sgothel> good .. this helped cleaning up things in our code .. dinner, laters
20130814 21:34:42 <Markt_> that explains why everything
20130814 21:34:44 <Markt_> thanks for ur help
20130814 21:34:51 <Markt_> progress
20130814 21:34:54 <Markt_> cya
20130814 21:35:14 * Markt_ (32c4d781@anon) Quit (Quit: Page closed)
20130814 22:40:21 * xranby (~xranby@anon) Quit (Ping timeout: 264 seconds)
20130814 23:37:34 * xranby (~xranby@anon) has joined #jogamp
20130815 03:59:48 <sgothel> timer timer timer timer - duh! :)
20130815 04:37:21 <sgothel> http://jogamp.org/git/?p=gluegen.git;a=commit;h=77687335f7fae3727c902c678b9525e6f4631da1
20130815 05:06:07 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20130815050607.html