#jogamp @ irc.freenode.net - 20141028 05:06:25 (UTC)

20141028 05:06:25 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20141027050625.html
20141028 05:06:25 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20141028050625.html
20141028 06:51:23 * monsieur_max (~maxime@anon) has joined #jogamp
20141028 07:25:10 * doev (~doev@anon) has joined #jogamp
20141028 07:34:48 * eclesia (~husky@anon) has joined #jogamp
20141028 07:34:54 <eclesia> good morning
20141028 07:37:15 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20141028 07:52:51 * doev (~doev@anon) Quit (Ping timeout: 265 seconds)
20141028 07:53:15 * doev (~doev@anon) has joined #jogamp
20141028 09:04:50 * monsieur_max (~maxime@anon) has joined #jogamp
20141028 11:07:42 * doev (~doev@anon) Quit (Ping timeout: 256 seconds)
20141028 11:08:14 * doev (~doev@anon) has joined #jogamp
20141028 12:22:04 * doev (~doev@anon) Quit (Ping timeout: 265 seconds)
20141028 12:23:15 * doev (~doev@anon) has joined #jogamp
20141028 12:59:29 * gouessej (5ee4b442@anon) has joined #jogamp
20141028 13:00:00 <gouessej> Hi
20141028 13:08:40 <eclesia> ho
20141028 13:27:19 * doev (~doev@anon) Quit (Ping timeout: 245 seconds)
20141028 13:28:13 * doev (~doev@anon) has joined #jogamp
20141028 13:28:17 <gouessej> sgothel: Sorry to disturb you again. I hope that nothing will prevent you from making another autobuild
20141028 13:49:14 <rmk0> so i'm using a scheduled executor to call a function that updates the current physics state
20141028 13:49:26 <rmk0> am using a fixed time step, and the function is called every 16.5ms
20141028 13:49:36 <rmk0> on linux, i get a consistent 16.5ms delta time
20141028 13:49:43 <rmk0> on windows, i get anything from 9ms to 30ms
20141028 13:49:53 <rmk0> is there... some way to get more accurate timing?
20141028 13:49:59 <gouessej> yes
20141028 13:50:21 <gouessej> Maybe just force the high precision timer with the famous hack
20141028 13:50:33 <rmk0> i don't know it
20141028 13:50:35 <rmk0> what's it?
20141028 13:50:54 <gouessej> There is a bug report about that and I use it in TUER
20141028 13:51:00 <gouessej> Wait a few seconds
20141028 13:51:04 <rmk0> no rush
20141028 13:51:18 * rmk0 idles
20141028 13:51:27 <gouessej> http://bugs.sun.com/view_bug.do?bug_id=6435126
20141028 13:51:49 <gouessej> Look at the workaround
20141028 13:52:00 * rmk0 eyes it
20141028 13:53:21 <rmk0> nasty
20141028 13:53:26 <rmk0> and fuck their attitude too
20141028 13:53:41 <rmk0> "this has been broken for too long, no use fixing it now"
20141028 13:53:57 <gouessej> lol yes
20141028 13:54:19 <sgothel> Platform.currentTimeMicros() or *Millis() to the rescue ?
20141028 13:54:38 <sgothel> @Julien .. I will try to finish my tasks today to kick off jenkins, yes
20141028 13:55:49 <gouessej> sgothel: Thanks. I will use it tomorrow then
20141028 13:58:37 <sgothel> so if things are broken for 'too long' .. no fix needed, cool :)
20141028 13:59:17 <rmk0> that bug report is a catastrophe of stupidity
20141028 13:59:30 <rmk0> just ... can't even conceive of the thinking behind some of the statements
20141028 13:59:42 <sgothel> inspires me to think about a timer API .. for various stimuli (time, vsync, ..)
20141028 14:00:04 <rmk0> it would be nice... i imagine there are ways to improve it by calling some native code
20141028 14:00:12 <sgothel> yup
20141028 14:00:15 <rmk0> means anyone doing it then has to produce code for all the platforms and so on
20141028 14:00:21 <rmk0> something jogl's already doing, naturally
20141028 14:00:45 <rmk0> suspect just a high resolution sleep() call would be enough
20141028 14:00:49 <sgothel> hooking on native OS timers .. or busy loop thread .. etc etc
20141028 14:04:04 <rmk0> i like that they introduced a whole new command line switch that can't work at all, but they prefer that it doesn't
20141028 14:05:55 * doev (~doev@anon) Quit (Ping timeout: 265 seconds)
20141028 14:06:42 * doev (~doev@anon) has joined #jogamp
20141028 14:27:27 <gouessej> The workaround isn't very complicated anyway
20141028 14:28:27 <gouessej> but I admit that I find it stupid to introduce a new completely broken switch
20141028 14:57:14 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20141028 15:08:36 <rmk0> heh... on windows, it seems like it's a bad idea to ever write to System.out
20141028 15:08:47 <rmk0> it causes a good ~30ms stall
20141028 15:08:57 <rmk0> assume it's grabbing some very expensive global lock
20141028 15:13:20 <zubzub> it's a bad idea to write on windows
20141028 15:13:22 <zubzub> agreed
20141028 15:13:52 <rmk0> no wonder so many games have internal consoles
20141028 15:13:57 <rmk0> didn't appreciate just how expensive it is
20141028 15:14:06 <rmk0> it's not expensive like that on linux or os x
20141028 15:25:15 * MacTuitui (~tuitui@anon) Quit (Ping timeout: 258 seconds)
20141028 15:25:55 * MacTuitui (~tuitui@anon) has joined #jogamp
20141028 16:07:34 * eclesia (~husky@anon) has left #jogamp
20141028 16:18:35 * monsieur_max (~maxime@anon) has joined #jogamp
20141028 16:30:05 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20141028 16:30:59 * monsieur_max (~maxime@anon) has joined #jogamp
20141028 16:52:31 <rmk0> hrm, this isn't going too well
20141028 16:53:09 <rmk0> enabling that stupid hack for the timers on windows helped, but i can't get reliably smooth animation across different platforms
20141028 16:53:36 <rmk0> using a scheduled executor on linux seems to give the best precision, but it's not great on windows
20141028 16:53:58 <rmk0> using a loop that calls Thread.sleep() with a time in milliseconds and nanoseconds works better on windows but worse on linux
20141028 16:54:37 <rmk0> basically have one thread producing new physics state at 60fps, and then a GLEventListener consuming those states at whatever is the display rate
20141028 16:54:59 <rmk0> the GLEventListener reuses whatever state it received last until it receives a new one
20141028 16:55:15 <rmk0> there's no locking or anything like that that could be causing stutter or otherwise weird behaviour
20141028 17:00:48 <gouessej> sgothel: Let me know when the next autobuild is going to be ready
20141028 17:02:17 <gouessej> rmk0: I thought that the hack would be enough
20141028 17:02:33 <rmk0> so did i, but... seems not
20141028 17:02:40 <rmk0> i'm not really sure what could be causing this
20141028 17:03:08 <rmk0> get some really bizarre behaviour on windows with the timed/scheduled executor
20141028 17:06:34 * doev (~doev@anon) Quit (Ping timeout: 255 seconds)
20141028 17:06:51 <rmk0> with the scheduled executor, i get smooth behaviour most of the time
20141028 17:07:05 <rmk0> but on windows, it's like every 10-15 seconds or so, the frame rate suddenly halves
20141028 17:07:13 <rmk0> lasts about 5 seconds or so, and then speeds up again
20141028 17:07:23 <rmk0> it's really hard to measure what's actually going on
20141028 17:07:36 <rmk0> the rendering frame rate remains the same, so it seems more like the physics thread starts lagging behind
20141028 17:08:30 <rmk0> is... kind of worrying
20141028 17:08:49 <rmk0> like, if i can't get a minimal example like this working nicely, it doesn't bode well for the rest of the stuff i've been working on
20141028 17:10:11 <gouessej> I will probably have the same problem when I separate the rendering and the physics
20141028 17:10:16 * xranby (~xranby@anon) Quit (Ping timeout: 244 seconds)
20141028 17:10:16 <gouessej> Good luck
20141028 17:10:20 * gouessej (5ee4b442@anon) Quit (Quit: Page closed)
20141028 17:11:59 * rmk0 eyes LockSupport.parkNanos
20141028 17:21:27 <rmk0> it seems like i get the best results on all platforms if i use a scheduled executor, updating the physics at 100hz, and rendering at whatever is the vsync rate
20141028 17:23:41 * xranby (~xranby@anon) has joined #jogamp
20141028 17:23:57 <rmk0> have no idea why 100hz specifically
20141028 17:24:01 <rmk0> any higher or any lower seems worse
20141028 17:24:16 <rmk0> vsync on both platforms turns out to be 60hz
20141028 18:27:07 <sgothel> earmarking adding a modern 'timer event' API/impl. to have event-listeners attached w/ optional blocking
20141028 18:27:34 <rmk0> it's still not clear what the problem actually is here
20141028 18:27:42 <rmk0> going to try to put together a suite of examples
20141028 18:28:08 <rmk0> unfortunately, measuring it turns out to be hard too, because most measuring schemes change the timing characteristics!
20141028 18:30:22 * monsieur_max (~maxime@anon) Quit (Ping timeout: 240 seconds)
20141028 18:31:13 <rmk0> sgothel: did you see http://waste.io7m.com/2014/10/27/ExampleReduced.java ?
20141028 18:31:47 <rmk0> is a minimal case that raises an exception when the window's closed
20141028 18:32:00 <rmk0> it's the setTitle call in the display() method that causes it
20141028 18:33:45 <sgothel> not yet looked at ..
20141028 18:33:54 <rmk0> it's not too serious
20141028 18:34:03 <rmk0> just... irritating
20141028 18:35:30 <sgothel> interesting .. have to make a unit test, on windows ? -> bug report
20141028 18:35:45 <rmk0> happens on all platforms i've tried
20141028 18:35:48 <rmk0> will file a bug shortly
20141028 18:35:59 <sgothel> seems like display is called, we still assume its all good (issue display()) but .. not
20141028 18:36:33 <sgothel> that bug should actually be visible all the time .. hmm, especially w/ X11/GLX
20141028 18:37:02 <rmk0> it'll randomly not occur
20141028 18:37:08 <rmk0> like... maybe one run in ten won't trigger it
20141028 18:43:06 <rmk0> ... which module does this belong to?
20141028 18:43:07 <rmk0> newt?
20141028 18:43:32 <sgothel> setTitle of a NEWT Window .. yes, NEWT
20141028 18:44:23 <sgothel> then we have to see whether the cause is the display call of an already disposed window (NEWT as well)
20141028 18:44:55 <sgothel> copy/paste exception pls
20141028 18:45:00 <sgothel> (in bug report)
20141028 18:45:11 <rmk0> yep
20141028 18:46:54 * monsieur_max (~maxime@anon) has joined #jogamp
20141028 18:52:46 <rmk0> sgothel: https://jogamp.org/bugzilla/show_bug.cgi?id=1098
20141028 18:54:33 <rmk0> not sure how to provide a better test... obviously needs manual intervention to close the window and trigger the bug
20141028 18:54:59 <rmk0> not something you'd want happening in the test suite
20141028 19:49:06 <rmk0> yow, may've discovered another one!
20141028 19:49:11 <rmk0> checking...
20141028 19:51:36 <sgothel> thx Mark, busy .. in between cooking .. etc, will find time tonight :)
20141028 19:51:57 <rmk0> hehe, no worries
20141028 19:52:00 <rmk0> don't rush yourself
20141028 20:04:45 <rmk0> https://jogamp.org/bugzilla/show_bug.cgi?id=1099
20141028 20:05:05 <rmk0> it's been that kind of day
20141028 20:06:09 <sgothel> do setFullscreen from a diff thread, look at our demos
20141028 20:06:30 <sgothel> i.e. its a heavy lifecycle issue .. can't do from display
20141028 20:07:06 <sgothel> if you have time: would be sweet if you can do junit test cases which I can simply pull (git)
20141028 20:07:41 <sgothel> (copy/paste one existing .. etc)
20141028 20:15:05 <rmk0> ah, right
20141028 20:15:17 <rmk0> er
20141028 20:15:33 <rmk0> yes on the test case thing, but... i'm doing setFullscreen from a KeyListener
20141028 20:17:35 <sgothel> see demos, AFAIK we spawn off to a dummy worker thread ..
20141028 20:17:44 <sgothel> key-input might be issued directly by EDT ..
20141028 20:17:50 <rmk0> oh, right
20141028 20:17:58 <sgothel> I use throw-away threads ..
20141028 20:19:43 <rmk0> where would be the right way to document this?
20141028 20:19:56 <rmk0> i can't really check all the demos every time i want to use an API function :D
20141028 20:20:01 <rmk0> *right place
20141028 20:20:13 <sgothel> haven't I added a note in the event listeners ?
20141028 20:20:16 <rmk0> the javadoc says nothing about calling setFullscreen from another thread
20141028 20:20:26 <sgothel> event listeners
20141028 20:21:19 <rmk0> i don't see anything about it in GLEventListener or KeyListener
20141028 20:21:38 <sgothel> nope .. :(
20141028 20:22:20 <sgothel> well .. IMHO it should be in .. err NEWTEventListener probably .. and a reference in the InputEvent implementation probably
20141028 20:22:32 <sgothel> I know .. quite hidden ..
20141028 20:22:55 <rmk0> do all of the window functions have these constraints?
20141028 20:23:00 <sgothel> rework my poor NEWT documentation .. (-> wiki) and add it there ..
20141028 20:23:09 <rmk0> i can appear to call warpPointer safely from display() and so on
20141028 20:23:18 <rmk0> seems like there should at least be notes on some of the functions
20141028 20:23:25 <sgothel> no .. should mark them 'lifecycle heavy'
20141028 20:23:28 <sgothel> yes
20141028 20:23:50 <sgothel> lifecycle heavy: all methods able to destroy / re-attach resources (surface/window/..) etc
20141028 20:24:00 <sgothel> fullscreen, reparent, ..
20141028 20:24:12 * rmk0 eyes it
20141028 20:24:15 <sgothel> destroy
20141028 20:24:36 <sgothel> so those shall not be issued from within 'EDT' related threads (ofc)
20141028 20:25:10 <sgothel> or .. better EDT = resource related threads and callbacks
20141028 20:25:54 <sgothel> a nice doc in the NEWTInputEvent mentioning the callback issue .. and in Window would be nice
20141028 20:26:19 <rmk0> right
20141028 20:26:37 <sgothel> *new bug report* ..
20141028 20:26:42 <sgothel> you or me ?
20141028 20:26:45 <sgothel> (doing it)
20141028 20:26:55 <rmk0> i was about to start attempting the docs
20141028 20:27:00 <sgothel> great
20141028 20:27:18 <sgothel> API doc: most important / 'tutorial' : nice to have
20141028 20:28:47 <sgothel> API doc is considered the 'spec' :)
20141028 20:38:52 <rmk0> is setVisible lifecycle heavy?
20141028 20:39:36 <sgothel> yes, iff window is not yet realized (triggers native creation) .. so .. 'yes, iff ..' :)
20141028 20:39:47 <sgothel> i.e. we do lazy initialization all over the place if possible
20141028 20:39:53 <rmk0> erk
20141028 20:40:01 <sgothel> na na .. its nice dude ..
20141028 20:40:25 <rmk0> i meant more that it's not so clear to me which methods are lifecycle heavy and which aren't
20141028 20:40:27 <sgothel> you can have your cheap objects .. w/o heavy load at instance creation
20141028 20:40:33 <sgothel> yeah ..
20141028 20:40:48 <sgothel> we will review this under the new bug report (you created ..)
20141028 20:40:57 <sgothel> pls put 'bug xxxx: ...' in commit msg
20141028 20:41:07 <sgothel> and git-sha1 in the SCM ref field
20141028 20:41:17 <sgothel> I will ofc walk over and review as well
20141028 20:41:36 <sgothel> good stuff - that this gets documented! thx!
20141028 20:44:39 <rmk0> https://jogamp.org/bugzilla/show_bug.cgi?id=1100
20141028 20:44:47 <rmk0> will submit some javadoc in a bit
20141028 20:45:18 <rmk0> doing it just in com.jogamp.newt.Window for now, until we decide where it's all going to go
20141028 20:45:21 <sgothel> excellent
20141028 20:45:40 <sgothel> great, I will also add a few notes later
20141028 20:45:57 <zubzub> glTexImage2D has 2 variants in jogl
20141028 20:46:00 <zubzub> one with a bytebuffer
20141028 20:46:07 <sgothel> what is my beef roast doing ? .. :)
20141028 20:46:10 <zubzub> and one with a long 'buffer_offset'
20141028 20:46:13 <zubzub> what's the difference?
20141028 20:46:56 * rmk0 smells burning from the kitchen
20141028 20:47:16 <rmk0> zubzub: in the olden days, glTexImage2D could take a pointer to memory allocated on the cpu
20141028 20:47:59 <rmk0> in modern opengl, it just takes a long offset in bytes for a currently bound buffer
20141028 20:48:12 <rmk0> who needs type safety?
20141028 20:48:35 <zubzub> you mean like a PBO?
20141028 20:48:49 <rmk0> yeah, think it would be in that case
20141028 20:49:23 <rmk0> they did the same with glBufferData and friends
20141028 20:49:33 <rmk0> i think... one of those
20141028 20:50:50 <rmk0> feel like i'm disarming land mines every time i try to use git
20141028 20:51:51 <zubzub> <3 git
20141028 20:52:06 <zubzub> it's actually pretty hard to make git lose data
20141028 20:54:35 <sgothel> and .. also use *TexSubImage* for updates -- which keeps the internal GL buffer intact
20141028 20:55:05 <sgothel> *dropped broccoli into pot .. dinner ready in a few minutes .. hmmm :)
20141028 20:55:52 <sgothel> *BufferSubData* .. <- same thing
20141028 20:56:02 <sgothel> BufferData will create a new GL memory instance
20141028 20:56:16 <sgothel> we have that well documented in our tracker
20141028 22:20:13 <zubzub> ah
20141028 22:20:17 <zubzub> good to know!
20141028 22:20:21 <zubzub> I fixed my memory leak
20141028 22:20:34 <zubzub> but it's still slow as hell (the texture updates)
20141028 22:20:49 <zubzub> so the next step is to gradually optimize
20141028 22:20:58 <zubzub> starting with subimage I guess
20141028 22:21:03 <zubzub> and ending somewhere with a PBO
20141028 23:07:26 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20141029 00:43:29 * xranby (~xranby@anon) Quit (Ping timeout: 256 seconds)
20141029 00:45:10 * xranby (~xranby@anon) has joined #jogamp
20141029 05:06:25 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20141029050625.html