JogAmp IRC Chat Logs

#jogamp @ irc.freenode.net - 20140210 05:05:44 (UTC)

20140210 05:05:44 -jogamp- Previous @ http://jogamp.org/log/irc/jogamp_20140209050543.html
20140210 05:05:44 -jogamp- This channel is logged @ http://jogamp.org/log/irc/jogamp_20140210050544.html
20140210 07:05:13 * [Mike] (~Mike]@anon) Quit ()
20140210 07:10:25 * jvanek (jvanek@anon) has joined #jogamp
20140210 07:38:33 * monsieur_max (~maxime@anon) has joined #jogamp
20140210 08:00:53 * woglinde (~henning@anon) has joined #jogamp
20140210 08:05:58 * eclesia (~husky@anon) has joined #jogamp
20140210 08:06:05 <eclesia> good morning
20140210 08:20:53 <monsieur_max> hi there
20140210 08:59:16 * hija (~hija@anon) has joined #jogamp
20140210 09:29:02 * hija (~hija@anon) Quit (Quit: hija)
20140210 10:10:38 * hija (~hija@anon) has joined #jogamp
20140210 11:03:58 <sgothel> Good morning
20140210 11:05:25 <hija> mornin sven
20140210 11:05:29 <hija> quick question
20140210 11:06:18 <hija> i have several notes about the NewtCanvasSWT and some probable ways to fix the positioning/resizing issues
20140210 11:06:27 <hija> but it needs explaining
20140210 11:06:37 <sgothel> go on ..
20140210 11:06:42 <hija> where should I put the notes?
20140210 11:06:48 <hija> just make a blog or smth?
20140210 11:07:13 <sgothel> is it for the user ? or is it your brainstorming for implementing a fix ?
20140210 11:07:19 <sgothel> or documenting the latter ?
20140210 11:07:28 <hija> brainstorming mostly
20140210 11:07:41 <sgothel> maybe in the bug report itself ..
20140210 11:07:57 <sgothel> and the resulting final thoughts in the source code
20140210 11:08:09 <sgothel> i.e. 'how and why it works' .. in source code
20140210 11:08:23 <hija> hmm
20140210 11:08:28 <sgothel> in case it is so curious
20140210 11:08:40 <sgothel> 'funny' .. i.e. magic code :)
20140210 11:08:44 <hija> no :P
20140210 11:08:55 <hija> its just a bit different from the implementation we currently have
20140210 11:08:59 <hija> i.e:
20140210 11:09:25 <sgothel> then put it in bug report at least, we can discuss it from there .. or here, while reading it there
20140210 11:09:27 <hija> unless you force the parent element of the canvas to have a fill layout of some sorts
20140210 11:09:46 <hija> you won't receive resize events
20140210 11:10:15 <sgothel> sounds very important .. and like the magic ingredient - pls put such magic in the source code!
20140210 11:10:15 <hija> which is fine, but the problem is that you also don't receive any events to trigger an update of position
20140210 11:10:40 <sgothel> great investigation - which may explain a lot
20140210 11:10:49 <sgothel> i.e. diff behavior of unit tests .. etc
20140210 11:11:26 <sgothel> and .. is there a way to mitigate it ?
20140210 11:11:38 <hija> there is also the issue of trusting SWT to give us the position the element is supposed to have on the screen and not us trying to calculate it
20140210 11:11:52 <hija> swt has a Control.toDisplay(0,0); thing
20140210 11:11:59 <sgothel> I remember your remark ..
20140210 11:12:11 <sgothel> great .. if that is working .. may replace getLOS
20140210 11:12:23 <sgothel> (but be aware on the SWT EDT ..)
20140210 11:12:28 <sgothel> *of*
20140210 11:12:31 <hija> edt?
20140210 11:12:47 <sgothel> the magic SWT Display Thread
20140210 11:13:01 <hija> ah, thats a new one
20140210 11:13:01 <sgothel> similar to AWT EDT, hence me calling it SWT EDT
20140210 11:13:04 <hija> what is that?
20140210 11:13:27 <sgothel> in AWT it's the one event dispatch thread (EDT)
20140210 11:13:41 <sgothel> SWT requires all ops to be run on the SWT thread (main thread - whatever)
20140210 11:13:46 <sgothel> you know it ..
20140210 11:13:57 <hija> oh
20140210 11:14:09 <sgothel> so getLOS using the simple cached parent location may not need to have it on the SWT thread
20140210 11:14:12 <hija> yeah thats why in osx you have to go -XstartOnFirstThread
20140210 11:14:15 <hija> or smth
20140210 11:14:18 <sgothel> yuip
20140210 11:14:31 <sgothel> .. and all the funny code in unit tests ..
20140210 11:14:38 <hija> meh
20140210 11:15:15 <sgothel> i.e. thats why even for NewtCanvasAWT .. we fallback to use AWT positions for getLOS
20140210 11:16:00 <sgothel> but maybe its easier here .. dunno
20140210 11:16:20 <hija> so newtcanvasSwt should update a variable of some sorts and getLOS use that?
20140210 11:17:12 <sgothel> you mean one of newtcanvasSwt's callbacks update the LOS all the time ? dunno how expensive that is
20140210 11:17:26 <hija> no no
20140210 11:18:42 <sgothel> the deadlock _threat_ is like: if( onSWT ) { runOnSWTAndWait(task); } else { task.run(); }
20140210 11:18:47 <hija> afaik now, getLOS is only called when we have an SWT.Resize event
20140210 11:18:58 <sgothel> the above will deadlock iff:
20140210 11:19:11 <sgothel> Thread: T-SWT -> T-User -> T-SWT
20140210 11:19:34 <sgothel> i.e. the resize will make a blocking callback to user, which will make a blocking callback to SWT
20140210 11:20:18 <sgothel> that is why .. NewtCanvasAWT uses a lock free path if AWT already acquired the tree lock ..
20140210 11:21:04 <sgothel> if a getLOS variant (non public) is only called from the SWT thread - we are clear!
20140210 11:21:16 <sgothel> but a public getLOS might not be so lucky :)
20140210 11:21:23 <sgothel> right ?
20140210 11:21:23 <hija> hmm
20140210 11:21:58 <hija> tbh my understanding of threads is still weak
20140210 11:22:03 <hija> but i sort of get it
20140210 11:22:04 <sgothel> above example:
20140210 11:22:13 <sgothel> SWT resize triggers GLEventListener reshape
20140210 11:22:14 <hija> that's why the brainstorming thing
20140210 11:22:42 <hija> yes
20140210 11:22:49 <sgothel> user reshape code does a blocking call on a diff. thread - which will lead to a blocking call to SWT -> deadlock
20140210 11:23:16 <sgothel> looks like 'academic' but .. we easily provoked it w/ NewtCanvasAWT
20140210 11:23:52 <sgothel> hence .. you can have a private getLOS which can be run w/o 'deadlock fear'
20140210 11:24:04 <sgothel> the public getLOS .. may need some more magic
20140210 11:24:13 <hija> what would be "user reshape code" ?
20140210 11:24:22 <sgothel> GLEventListener.reshape()
20140210 11:24:33 <hija> i see
20140210 11:24:53 <sgothel> 'usually', i.e. w/ an Animator - they are decoupled
20140210 11:25:08 <sgothel> but w/o such .. code is run 'in place'
20140210 11:25:16 <sgothel> i.e. on SWT thread
20140210 11:25:34 <sgothel> so if that one delegates for whatever reason .. and calls back to SWT .. *bang*
20140210 11:25:49 <sgothel> sure - this should not be done ..
20140210 11:26:23 <sgothel> i.e. we use a new arbitrary thread and execute w/o locking, if you want to change a NEWT window from such an event handler
20140210 11:26:33 <sgothel> .. brainstorming ..
20140210 11:26:42 <hija> trying to follow :D
20140210 11:26:55 <sgothel> so .. why not impl. your getLOS .. and see what happens .. while adding good use cases
20140210 11:27:15 <sgothel> ^^ ==> new Thread() { /* your run method */ }.start()
20140210 11:27:23 <sgothel> this is non blocking
20140210 11:27:54 <sgothel> but if a user would do a 'invokeAndWait(..)' .. it could become a deadlock
20140210 11:28:25 <sgothel> TL;DR .. this is why we used the SWT position :)
20140210 11:28:38 <sgothel> but you have proven .. it cannot be trusted
20140210 11:29:10 <hija> there is another way
20140210 11:29:23 <sgothel> btw .. after finding a solution for NewtCanvasSWT - maybe you can perform same fixes on our SWT GLCanvas
20140210 11:29:54 <hija> SWT seems to be delegating a method "setBounds(int x, int y, int w, int h); down its children
20140210 11:30:07 <hija> i was thinking of that, as long as the newt one is done
20140210 11:30:25 <hija> so maybe instead of waiting for the listener
20140210 11:30:32 <hija> override that
20140210 11:30:42 <hija> and send a newtChild.setPosition(x,y);
20140210 11:30:47 <hija> and a newtChild.setSize(w, h);
20140210 11:31:10 <hija> (along of course with super.setBounds(x,y,w,h);
20140210 11:31:11 <hija> )
20140210 11:31:34 <sgothel> ^^ is more reliable than 'SWT.Resize' event ?
20140210 11:31:49 <hija> it's triggered on resize and on move
20140210 11:32:09 <hija> (within the SWT window)
20140210 11:33:14 <hija> though as far as i understand listeners are better for multithreading
20140210 11:33:37 <sgothel> updateSizeCheck: only triggers newt's setSize if size changed ..
20140210 11:34:23 <hija> then instead of newtChild.setSize(w, h); just call updateSizeCheck(); ?
20140210 11:34:26 <sgothel> but all the setSize and setPostion calls to NEWT are 'active' things .. i.e. they will perform a change to the native NEWT window
20140210 11:35:02 <sgothel> SWT's position change shall not be propagated to NEWT child window, which shall remain (0/0)
20140210 11:35:24 <sgothel> iff you figured that 'SWT.Resize' event is _not_ sufficient ..
20140210 11:35:59 <sgothel> and/or the SWT getClientArea()
20140210 11:36:20 <hija> if we are resizing all is well,
20140210 11:36:21 <sgothel> i.e. we rely on getClientArea() to work properly
20140210 11:36:44 <hija> but unless we use a fill layout
20140210 11:36:47 <hija> no resizing
20140210 11:36:52 <hija> thus no positioning
20140210 11:37:37 <sgothel> great .. if the alternative setBounds works for all cases as a replacement ..
20140210 11:37:48 <hija> sorry i meant "if we don't use a fill layout, no resizing, no positioning"
20140210 11:37:50 <sgothel> not sure w/ the positioning
20140210 11:38:30 <sgothel> ah .. so you say the NEWT child window _must_ be relatively positioned inside the SWT parent ?
20140210 11:38:44 <sgothel> for non fill-layouts
20140210 11:39:00 <hija> yes
20140210 11:39:02 <hija> well
20140210 11:39:04 <sgothel> sure we need to test this on all platforms then ..
20140210 11:39:31 <hija> i did an osx implementation
20140210 11:39:35 <hija> testing now on windows
20140210 11:39:47 <sgothel> can you do an SWT screenshot or something (a picture of the SWT component would suffice)
20140210 11:40:02 <sgothel> (with the NEWT child ofc)
20140210 11:40:14 <hija> that's why I asked where should I put these notes :p
20140210 11:40:17 <hija> pictures
20140210 11:40:18 <hija> heheheh
20140210 11:40:27 <sgothel> having that in the unit test .. would help us
20140210 11:40:39 <sgothel> bug report
20140210 11:40:57 <sgothel> and also add a link to this conversation there .. maybe
20140210 11:41:28 <sgothel> http://jogamp.org/log/irc/jogamp_20140210050544.html#l15
20140210 11:41:35 <hija> isn't there a "development department" in the forums?
20140210 11:41:49 <sgothel> yes .. but that I consider transient
20140210 11:42:05 <sgothel> so the bug report is linked in the git commit and is persistent and trackable
20140210 11:42:33 <sgothel> the git commit's sha-1 shall also be cross referenced w/ the bug report
20140210 11:42:39 <sgothel> (the SCM field)
20140210 11:42:53 <sgothel> it's holistic :)
20140210 11:43:07 <hija> :D
20140210 11:43:23 <sgothel> from coast-to-coast .. incl. the unit tests .. and the actual jenkins builds / unit-test runs ..
20140210 11:44:30 <sgothel> forum is like '1st contact' and 'public relations' IMHO
20140210 11:44:31 <hija> should I open a new bug "NewtCanvasSWT positiong/resizing issues" and put everything in there?
20140210 11:44:47 <sgothel> that would be great - if not covered by an existing bug report
20140210 11:44:55 <hija> they are very specific
20140210 11:45:01 <sgothel> great!
20140210 11:45:06 <hija> 822, 956, 672
20140210 11:45:15 <sgothel> all daisy chained :)
20140210 11:45:20 <hija> :D
20140210 11:45:28 <sgothel> yeah .. make a new one
20140210 11:45:41 <sgothel> and daisy chain it .. i.e. depend on <old-bug-report>
20140210 11:45:56 <hija> yes yes
20140210 11:45:57 <hija> btw
20140210 11:46:09 <hija> I select product = newt
20140210 11:46:17 <hija> but there is no "swt" component
20140210 11:46:22 <sgothel> oh ..
20140210 11:46:27 <sgothel> will add it .. one sec ..
20140210 11:46:57 <hija> or i select jogl? there is swt but no newt
20140210 11:46:59 <sgothel> Jogl has a 'swt' component
20140210 11:47:10 <hija> yes
20140210 11:47:10 <sgothel> ah .. ok .. add swt to newt as well
20140210 11:50:30 <sgothel> added .. and your are assignee :)
20140210 11:51:50 <hija> haha
20140210 11:51:51 <hija> :D
20140210 11:52:53 <sgothel> put you as assignee of all https://jogamp.org/bugzilla/showdependencytree.cgi?id=674&hide_resolved=0
20140210 11:54:28 <sgothel> btw .. at FOSDEM we had a small chat w/ Mike from Eclipse .. he does some legal stuff and manages the whole if I remember correctly
20140210 11:55:12 <sgothel> I told him .. some legal analysis is pending since one lawyer left - and maybe some more collab may be needed
20140210 11:55:42 <sgothel> how is the situation .. ? Eclipse and JOGL ? Anybody using it 'there' ?
20140210 11:56:00 <sgothel> or anybody would like to use it, but can't properly yet ?
20140210 11:56:22 <sgothel> do they have a 'JOGL' channel or something where they discuss things related ?
20140210 11:57:14 <sgothel> Later I will sent him an email about the status .. I will copy you to it.
20140210 11:57:26 <hija> https://jogamp.org/bugzilla/showdependencytree.cgi?id=674
20140210 11:57:29 <hija> good
20140210 11:58:06 <sgothel> perfect
20140210 11:58:35 <sgothel> .. and the [re-]display issue maybe
20140210 11:59:07 <sgothel> plus: don't they all also apply to our SWT GLCanvas .. i.e. bugs 969... ?
20140210 11:59:52 <hija> don't know
20140210 11:59:59 <sgothel> i.e. when you fix it for NewtCanvasSWT .. maybe do it for GLCanvas as well as long your memory is fresh ..
20140210 12:00:01 <hija> I haven't touched that yet
20140210 12:00:09 <sgothel> i.e. make a unit test testing both
20140210 12:00:36 <hija> if I manage to wrap my mind around newtcanvasswt sure
20140210 12:00:41 <hija> i'll take a look
20140210 12:00:45 <sgothel> awesome
20140210 12:00:53 <hija> but let's keep them seperate for the moment
20140210 12:01:06 <hija> btw, when I made an eclipse view
20140210 12:01:15 <hija> with a newtcanvasswt
20140210 12:01:29 <hija> if you pull the view out to another window
20140210 12:01:40 <hija> the canvas goes to the back (in osx)
20140210 12:02:04 <sgothel> reparenting issue
20140210 12:02:19 <hija> overriding SWT's Control.reskin(int flags)
20140210 12:02:37 <sgothel> I would assume: pull-out: newt [invisible, top-level] - pull-on: newt [visible, child]
20140210 12:02:40 <hija> and putting validateNative() in fixed
20140210 12:02:42 <hija> it
20140210 12:02:56 <sgothel> *pull-in*
20140210 12:03:58 <sgothel> validateNative() is more the lazy creation
20140210 12:04:05 <sgothel> assuming nativeWindow == null
20140210 12:04:20 <sgothel> pull-out/in: is more about reparenting
20140210 12:04:44 <sgothel> so your 'reskin' may do the above pull-out/pull-in
20140210 12:04:54 <hija> how?
20140210 12:04:56 <hija> method?
20140210 12:04:57 <sgothel> pull-out: newt [invisible, top-level] - pull-in: newt [visible, child]
20140210 12:05:34 <sgothel> reparentWindow(..) seems to do all that
20140210 12:06:05 <hija> i think i tried it, but will do again
20140210 12:06:20 <sgothel> maybe it does more than that .. (setEnable(..) etc ..) since only used for the creation process
20140210 12:06:38 <sgothel> but the setVisible/reparentWindow calls shall be done in reskin ..
20140210 12:06:56 <sgothel> configureNewtChild(..) is already done
20140210 12:07:19 <hija> i'll rebuild with reparent hold on
20140210 12:07:30 <sgothel> maybe add a param to reparentWindow(..) for this case
20140210 12:07:56 <sgothel> "set SWT EDT and start it" <- this shall not be perfomed ofc !
20140210 12:09:07 <sgothel> IMHO rename reparentWindow -> attachNewtWindow
20140210 12:09:25 <sgothel> and create a plain reparentWindow method w/ minimal calls (visible and reparent)
20140210 12:09:44 <sgothel> (or something similar)
20140210 12:10:00 <hija> will do
20140210 12:10:12 <hija> using it directly btw does not work
20140210 12:10:42 <sgothel> yeah .. switching the EDT ..etc ..
20140210 12:30:46 <hija> it seems validateNative works because it creates a new SWTNativeWindow...
20140210 12:43:51 <sgothel> sure we shall reuse that one
20140210 12:45:12 <sgothel> iff .. the actual SWT native window did not change .. hmm
20140210 12:45:33 <sgothel> maybe it changes (pull-out: destroy, pull-in: re-create) ?
20140210 12:50:36 <hija> well i don't know
20140210 12:50:55 <hija> what are the consequences of recreating it?
20140210 12:51:04 <sgothel> SWTAccessor.getWindowHandle(this) <- do validate ..
20140210 12:51:25 <sgothel> iff changes, we need a new SWTNativeWindow
20140210 12:51:36 <sgothel> (pull-in, i.e. becomes valid again)
20140210 12:51:36 <hija> ok hold on
20140210 12:54:45 <hija> native Handle 140509586886384
20140210 12:54:45 <hija> SWTAccessor 140509586886384
20140210 12:54:57 <hija> looks the same to me
20140210 12:55:51 <hija> probably do an actual ==
20140210 12:59:55 <hija> even if I recreate the window it gets the same handles as the previous one
20140210 13:00:06 <hija> -handle
20140210 13:00:12 <sgothel> that is .. interesting :)
20140210 13:00:43 <sgothel> so reusing existing SWTNativeWindow should be fine w/ simple setVisible/reparent then ..
20140210 13:01:56 <hija> newtChild.setVisible(false);
20140210 13:01:56 <hija> newtChild.reparentWindow(nativeWindow, -1, -1, Window.REPARENT_HINT_BECOMES_VISIBLE);
20140210 13:01:57 <hija> newtChild.setVisible(true);
20140210 13:02:04 <hija> like this/
20140210 13:02:28 <sgothel> w/o setVisible(true) for pull-out .. I assume, since the pulled-out is invisible by nature ?
20140210 13:02:48 <sgothel> and: reparentWindow(..) setVisible(true) <- for pull-in ?
20140210 13:03:08 <sgothel> thats .. IMHO the normal lifecycle for other use cases (NewtCanvasAWT .. etc)
20140210 13:03:21 <sgothel> but not sure about semantics of a pulled-out SWT component
20140210 13:03:38 <sgothel> in AWT it's considered 'dead' .. i.e. not displayable
20140210 13:03:48 <sgothel> (no native [parent] peer)
20140210 13:04:37 <hija> brb food
20140210 14:01:51 <hija> back
20140210 14:21:15 <hija> it seems that nativeWindow = new SWTNativeWindow(nativeWindow.config, nativeWindow.nativeWindowHandle);
20140210 14:21:20 <hija> works...!
20140210 14:38:42 <hija> found it!
20140210 14:38:47 <hija> sgothel
20140210 14:39:20 <hija> reparenting the window has a: if(newParentWindow != getParent()) {
20140210 14:39:27 <hija> which blocks something...
20140210 14:40:55 <hija> in WindowImpl.java
20140210 14:41:17 <hija> line 1301
20140210 15:06:19 * jvanek (jvanek@anon) Quit (Ping timeout: 245 seconds)
20140210 15:11:04 <sgothel> } else if(newParentWindow != getParent()) {
20140210 15:11:04 <sgothel> // Case: Parent's native window realized and changed
20140210 15:11:05 <sgothel> if( !isNativeValid() ) {
20140210 15:11:26 <sgothel> in: // Case: Child Window
20140210 15:12:33 <sgothel> } else if ( forceDestroyCreate || !NewtFactory.isScreenCompatible(newParentWindow, screen) ) {
20140210 15:12:33 <sgothel> // Destroy this window, may create a new compatible Screen/Display, while trying to preserve resources if becoming visible again.
20140210 15:12:33 <sgothel> ^^ goes here ?
20140210 15:12:55 <sgothel> stack trace .. hmm
20140210 15:14:58 <hija> if the operation is: operation = ReparentOperation.ACTION_NATIVE_REPARENTING;
20140210 15:15:06 <hija> it works
20140210 15:15:18 <hija> instead of operation = ReparentOperation.ACTION_NOP
20140210 15:16:47 <hija> but i can't pinpoint exactly which operation revives the window
20140210 15:24:28 <sgothel> the reparent shall happen when you pull-out (w/ null parent) and then you push-in (w/ valid parent handle)
20140210 15:24:43 <sgothel> IMHO .. then you will have a proper behavior
20140210 15:25:02 <sgothel> i.e. both resulting in ReparentOperation.ACTION_NATIVE_REPARENTING
20140210 15:25:41 <sgothel> pull-out:
20140210 15:25:43 <sgothel> newtChild.setVisible(false);
20140210 15:25:43 <sgothel> newtChild.reparentWindow(null, -1, -1, 0 /* hints */);
20140210 15:25:48 <sgothel> push-in:
20140210 15:25:57 <sgothel> newtChild.reparentWindow(nativeWindow, -1, -1, Window.REPARENT_HINT_BECOMES_VISIBLE);
20140210 15:25:57 <sgothel> newtChild.setVisible(true);
20140210 15:26:16 <sgothel> newtChild.sendWindowEvent(WindowEvent.EVENT_WINDOW_RESIZED); // trigger a resize/relayout to listener
20140210 15:26:51 <sgothel> w/ SWTNativeWindow nativeWindow
20140210 15:27:35 <hija> hmmm lets see
20140210 15:33:29 <hija> swt does not agree :P
20140210 15:33:47 * jvanek (jvanek@anon) has joined #jogamp
20140210 15:35:16 <hija> ok now it did
20140210 15:35:31 <hija> but it does exhibit some odd behaviour...
20140210 15:39:10 <hija> if you have setVisible(false);
20140210 15:39:19 <hija> dragging the view out to a standalone window hides all of eclipse
20140210 15:39:45 <hija> otherwise the window goes there faster
20140210 15:43:54 <sgothel> oh ..
20140210 15:44:16 <sgothel> so the setVisible(false) on NEWT (still a child) propagates to the SWT window ?
20140210 15:44:40 <sgothel> then .. reverse: reparentWindow(null) .. setVisible(false)
20140210 15:44:51 <sgothel> weird thought ..
20140210 15:45:06 <sgothel> which native TK ? X11/GTK ? OSX ? GDI ?
20140210 15:46:45 <hija> osx
20140210 15:47:25 <sgothel> the above ops (reparentWindow/setVisible) are on the newt child right ? interesting
20140210 15:48:00 <sgothel> lets see the NEWT OSX setVisible code ..
20140210 15:50:17 <hija> yes newtChild
20140210 15:51:55 <sgothel> hmm seems to do the right thing, orderOut and set size/pos
20140210 15:52:25 <hija> when I do it the other way around this does not happen
20140210 15:52:41 <hija> from the standalone window back in eclipse's main
20140210 15:53:32 <sgothel> if( NULL == pWin || !pWinVisible ) {
20140210 15:53:32 <sgothel> [mWin orderOut: mWin];
20140210 15:53:32 <sgothel> } else {
20140210 15:53:32 <sgothel> [mWin orderBack: mWin];
20140210 15:53:32 <sgothel> }
20140210 15:54:16 <hija> ??
20140210 15:54:24 <hija> i didn't go that deep
20140210 15:54:25 <sgothel> NEWT's orderOut native code
20140210 15:57:13 <sgothel> looks like orderOut does cause trouble here .. i.e. parent is !visible
20140210 15:57:39 <sgothel> but they are all 'chained up' it seems ?
20140210 15:59:05 <hija> you lost me here :)
20140210 15:59:41 <sgothel> situation: NEWT's setVisible(false) renders the whole SWT application invisible
20140210 15:59:59 <sgothel> NEWT window is a child window of an OSX parent (an SWT component)
20140210 16:00:18 <hija> yes
20140210 16:00:35 <sgothel> setVisible(false) causes a native orderOut or orderBack in NEWT's native OSX code
20140210 16:00:54 <sgothel> it seems that orderOut is triggered .. and the whole window-tree goes of the screen
20140210 16:01:12 <hija> could be
20140210 16:01:25 <hija> orderout throws the whole app off screen?
20140210 16:01:37 <hija> it doesnt close it...
20140210 16:01:43 <hija> it just throws it back
20140210 16:01:44 <sgothel> at least this is what you have seen right ?
20140210 16:01:48 <sgothel> ah
20140210 16:01:57 <hija> sorry should have been clearer
20140210 16:02:11 <hija> it sort of blinks and ...
20140210 16:02:12 <hija> wait
20140210 16:02:44 <sgothel> ^^ we call either orderOut or orderBack .. and it seems it affects the parent window (which should not)
20140210 16:03:26 <sgothel> so a remedy (maybe ugly) is to reparent first - however the reparent itself will call setVisible(false) IMHO
20140210 16:04:03 <sgothel> (^^ only on X11 - so we shall be fine)
20140210 16:04:25 <sgothel> nevertheless .. 'orderOut' needs to be fixed it seems
20140210 16:04:59 <hija> yes, it sort of blinks and throws me to the previously opened window
20140210 16:05:11 <hija> not window
20140210 16:05:12 <hija> app
20140210 16:06:02 <sgothel> (04:25:41 PM) sgothel: pull-out:
20140210 16:06:02 <sgothel> (04:25:43 PM) sgothel: newtChild.reparentWindow(null, -1, -1, 0 /* hints */);
20140210 16:06:02 <sgothel> (04:25:43 PM) sgothel: newtChild.setVisible(false);
20140210 16:06:02 <sgothel> (04:25:48 PM) sgothel: push-in:
20140210 16:06:02 <sgothel> (04:25:57 PM) sgothel: newtChild.reparentWindow(nativeWindow, -1, -1, Window.REPARENT_HINT_BECOMES_VISIBLE);
20140210 16:06:03 <sgothel> (04:25:57 PM) sgothel: newtChild.setVisible(true);
20140210 16:06:28 <sgothel> .. and mark it as a workaround for this orderOut bug .. :-/
20140210 16:06:59 <hija> well I have to document everything that has been said untill now first :p
20140210 16:07:49 <sgothel> thinking about it .. need to create / test NEWT window parenting on OSX .. hmm
20140210 16:08:05 <sgothel> tbh .. abandoned that a bit ..
20140210 16:08:21 <hija> :p
20140210 16:08:36 <hija> with setvisible afterwards seems to be sluid
20140210 16:08:37 <hija> fluid
20140210 16:08:42 <sgothel> great progress - yeah, you have chosen the most troublesome platform to start w/ :)
20140210 16:08:46 <hija> newt window sort of jumps ahead
20140210 16:09:06 <sgothel> yeah .. need to find a good setVisible(false) for NEWT on OSX ..
20140210 16:09:42 <hija> ok i am back to the resize/position issue
20140210 16:10:23 <hija> even if I override swt's setBounds() method
20140210 16:10:43 <hija> and do newtChild.setPosition(x,y)
20140210 16:11:00 <hija> since x,y is relative to the parent element
20140210 16:11:07 <hija> it does not move
20140210 16:11:34 <hija> because WindowImpl.java line 2090:
20140210 16:11:34 <hija> if ( !isFullscreen() && ( getX() != x || getY() != y ) ) {
20140210 16:13:39 <sgothel> so hasPos == shallPos ?
20140210 16:14:14 <hija> relative to the parent yes
20140210 16:14:29 <hija> if the parent moves though...
20140210 16:14:37 <sgothel> I see .. and our OSX NEWT reconfig impl .. indeed uses the LOS itself
20140210 16:14:44 <sgothel> darn
20140210 16:15:09 <hija> strategy?
20140210 16:15:22 <hija> document everyhting? :P
20140210 16:16:31 <sgothel> we could relax this condition for child windows
20140210 16:16:37 <sgothel> in the end - it's a user call
20140210 16:17:11 <sgothel> ( getX() != x || getY() != y ) -> ( getX() != x || getY() != y || null!=getParentWindow() )
20140210 16:18:12 <sgothel> ^^ 'parentWindow' that is
20140210 16:19:35 <hija> now it follows
20140210 16:19:54 <sgothel> great
20140210 16:20:48 <hija> as null!=getParent()
20140210 16:22:46 * jvanek (jvanek@anon) Quit (Quit: Leaving)
20140210 16:23:40 <sgothel> we may throw out the position constraints all-together .. if you seem fit .. hmm, but for top-level it should be find right ?
20140210 16:25:12 <hija> what exactly is top level?
20140210 16:25:18 <hija> standalone window?
20140210 16:25:18 <sgothel> no parent
20140210 16:25:20 <sgothel> yup
20140210 16:25:24 <hija> guess so
20140210 16:28:55 <sgothel> when you have a unit test w/ commit for me to test, I will test a change of setVisible on OSX to fix that issue
20140210 16:29:07 <sgothel> probably need to use NSView setHidden
20140210 16:29:13 <sgothel> if a child window
20140210 16:36:31 <hija> windows does not accept my positioning tricks
20140210 16:36:43 <hija> there it sort of works without all this definition
20140210 16:39:04 <sgothel> so on window it's a 'proper' child window respecting it's rel. position ?
20140210 16:39:10 <sgothel> 'good' then
20140210 16:39:17 <sgothel> probably same on X11
20140210 16:39:56 <hija> i don't know I need to investigate how these calls for repositioning trickle down
20140210 16:40:25 <sgothel> i.e. all this child window positioning depends on the TK ofc
20140210 16:40:37 <hija> swt?
20140210 16:40:48 <sgothel> the native underlying TK ..
20140210 16:40:52 <hija> or the native native thing
20140210 16:40:54 <sgothel> OSX, GDI, X11/GTK
20140210 16:41:43 <hija> but shouldn't we unify them at the first level we interface with them?
20140210 16:41:56 <sgothel> if possible .. ofc
20140210 16:42:10 <sgothel> hence on OSX we use the LOS for child windows ..
20140210 16:42:34 <sgothel> hence your code simply should work 'now'
20140210 16:43:10 <sgothel> i.e. diff is to know when to make the setPosition call .. yes, this is odd for OSX
20140210 16:43:30 <sgothel> i.e. we would need to see how to do it w/ NSView/NSWindow .. on NEWT
20140210 16:43:39 <sgothel> if even possible
20140210 16:56:45 * monsieur_max (~maxime@anon) Quit (Quit: Leaving.)
20140210 17:10:02 * woglinde (~henning@anon) Quit (Ping timeout: 247 seconds)
20140210 17:11:37 <sgothel> NEWT OSX: Confirmed that client window setVisible is broken ..
20140210 17:14:44 <hija> yes?
20140210 17:17:28 <sgothel> yup .. testing w/ TestParenting01NEWT now ..
20140210 17:17:46 <sgothel> added a setVisible toggle in either mode (top-level/child) .. etc
20140210 17:17:54 <sgothel> doesn't work as expected
20140210 17:33:54 <hija> I don't understand how it's possible for the window to not be reconfiguring in windows, but moving properly
20140210 17:34:59 <sgothel> it all depends on how the native TK positions and handles child windows
20140210 17:35:25 <sgothel> i.e. on OSX it's using LOS .. where all others use the child location ..
20140210 17:35:38 <sgothel> also: all others move the child window properly ..
20140210 17:35:46 <sgothel> and it also depends on SWT's impl. ofc
20140210 17:37:10 * [Mike] (~Mike]@anon) has joined #jogamp
20140210 17:38:20 <hija> so in a sense
20140210 17:38:40 <hija> you could create a child window in osx anywhere on screen no matter the app you are in
20140210 17:38:56 <hija> but in windows you have to be relative to the app window?
20140210 17:39:15 <sgothel> that is my understanding and experience yup
20140210 17:39:48 <sgothel> or - I programmed that child window thingy on OSX completly wrong
20140210 17:39:52 <hija> so getLocationOnScreen should mimic windows' behaviour?
20140210 17:39:53 <hija> hehehe
20140210 17:40:14 <sgothel> .. for example .. if the child window moves out of parent (on OSX) it won't get clipped ..
20140210 17:40:22 <sgothel> getLOS should be all the same sure
20140210 17:40:30 <hija> yes thats another problem
20140210 17:41:36 <hija> but it does not happen with com.jogamp.opengl.swt.GLCanvas
20140210 17:42:04 <hija> because its not a native window?
20140210 17:42:24 <sgothel> *scratching head* - at least on X11 it is a child native window ..
20140210 17:47:07 <sgothel> http://jogamp.org/git/?p=jogl.git;a=commit;h=c3c204a2e374c1dc4c1fb51f15444e5b92850839
20140210 17:47:13 <sgothel> try this one pls .. dinner - laters
20140210 17:47:34 <hija> that was fast
20140210 17:58:26 <hija> the test passes, although I am not entirely sure what was supposed to be happening
20140210 17:59:22 <hija> in the eclipse plugin, reskinning still throws the whole app behind the next one in display order
20140210 18:00:44 * monsieur_max (~maxime@anon) has joined #jogamp
20140210 18:40:50 <sgothel> back ..
20140210 18:41:17 <sgothel> well, the child window shall disappear (not occluding the parent window) and reappear ..
20140210 18:41:35 <sgothel> but looks like something different is being used in SWT/OSX
20140210 18:42:38 <sgothel> (OSX/SWT) maybe they listen on some 'hidden' event and all go hidden .. or similar
20140210 19:16:37 * hija (~hija@anon) Quit (Quit: hija)
20140210 19:37:42 * monsieur_max1 (~maxime@anon) has joined #jogamp
20140210 19:41:19 * monsieur_max (~maxime@anon) Quit (Ping timeout: 260 seconds)
20140210 19:46:50 * Eclesia1 (~eclesia@anon) has joined #jogamp
20140210 19:47:20 * eclesia (~husky@anon) Quit (Disconnected by services)
20140210 19:47:26 * Eclesia1 is now known as eclesia
20140210 19:47:48 <eclesia> hi
20140210 19:48:06 * eclesia1 (~husky@anon) has joined #jogamp
20140210 19:52:53 <eclesia> I have something strange with the stencil buffer.
20140210 19:53:16 <eclesia> I made an FBO with multisampled texture both for color and depth/stencil
20140210 19:53:54 <eclesia> but when I try to make a clip effect, it does not work when the multisampling is activated
20140210 19:54:26 <eclesia> with a normal texture (no multisampling) it works fine.
20140210 19:55:04 <eclesia> any idea ?
20140210 20:01:52 * odin_ (~Odin@anon) Quit (*.net *.split)
20140210 20:07:15 * hija (~hija@anon) has joined #jogamp
20140210 20:08:27 <hija> https://jogamp.org/bugzilla/show_bug.cgi?id=969
20140210 20:11:22 * eclesia found his bug, was attached as a DEPTH and not DEPTH_STENCIL type
20140210 20:14:20 * woglinde (~henning@anon) has joined #jogamp
20140210 20:25:03 * hija (~hija@anon) Quit (Quit: hija)
20140210 20:38:08 * hija (~hija@anon) has joined #jogamp
20140210 21:59:51 * void256 (~void@anon) has joined #jogamp
20140210 22:08:07 * monsieur_max1 (~maxime@anon) has left #jogamp
20140210 22:27:49 * eclesia (~eclesia@anon) Quit (Quit: Leaving.)
20140210 23:21:10 * void256 (~void@anon) Quit (Remote host closed the connection)
20140210 23:41:11 * woglinde (~henning@anon) Quit (Ping timeout: 260 seconds)
20140211 00:06:07 * sgothel (~sgothel@anon) Quit (Read error: Connection reset by peer)
20140211 02:50:24 * [Mike] (~Mike]@anon) Quit ()
20140211 04:01:39 * [Mike] (~Mike]@anon) has joined #jogamp
20140211 05:05:44 -jogamp- Continue @ http://jogamp.org/log/irc/jogamp_20140211050544.html