Bug 484

Native SWT Binding Test

Hi all .. a 1st experimental demo for a native SWT / JOGL binding
working on Linux and Windows, both 32 and 64bit.

---

New GLDrawableFactory createProxySurface(..) method
  http://jogamp.org/git/?p=jogl.git;a=commit;h=254052b54cebdb957d83e46e377534ef263d6029

Pimp up SWTAccessor for our needs:
  http://jogamp.org/git/?p=jogl.git;a=commit;h=f9ae06b4df8daa5e780e392543cb06cb9a6293c9
  http://jogamp.org/git/?p=jogl.git;a=commit;h=e0b2133b1dafef6750885d53fe85e2bc9530c2c9

The new native test case/impl:
  http://jogamp.org/git/?p=jogl.git;a=commit;h=10ea39d665f0cb50204d1965a0739ca15119e86f

---

Works with OSX/Cocoa as well now:

  http://jogamp.org/git/?p=jogl.git;a=commit;h=83570ff52f67d8f0f7fe978e178bf7825041bee3
  http://jogamp.org/git/?p=jogl.git;a=commit;h=c1e542ad0150e5327b1ed9d9980d4eeb81720cde

---

Now we can see how to make a nice integration,
ie using NEWT or keep it special in the SWT realm.

Cheers, Sven

Hi Sven,

Could you elaborate a little on the difference between "having a nice integration" and "leave it in the SWT realm"?

What do you mean by that? (Please, keep in mind I'm a NEWT profane.)

How far are we from this:

import jogl.blabla.swt.GLCanvas;

// get/set capabilities
GLCanvas canvas = new GLCanvas(composite, SWT.NO_REDRAW);
// use as gl drawable...

Isn't this more or less what we are aiming to?


Regards,
Carlo

Hi Sven,

I made a first attempt at implementing an SWT GLCanvas. I've sent a pull request from github (I'm new to this workflow, please bear with me). This is a sort of "proof of concept": it's ugly and probably not the way you intended it to be done, but it's a start.

Hey Wade! Check this out! We have some kick-ass multisampling going on here!! :-)

It's looking good! I put my comment on the pull request :) I think (just my opinion, you're doing the real work here) that the easier it is to convert legacy SWT code to your new GLCanvas, the more successful this will be. This could very well become the default way to do OpenGL in SWT, since the original GLCanvas is no longer being extended.

again: Thank you for picking up this work item.

As mentioned I would love to also see a GLAutoDrawable implementation, sure.

Hence we would have 2 'interfaces'/scenarios to be implemented
  1) 'Old' inofficial SWT GLCanvas interface
  2)  JOGL's GLAutoDrawable

We have to see if we shall impl. those independent or in one impl. class.
Sure, if the latter gets too complicated, 2 simple impl. might be better.

Benefits of (1)
  - make shifting to JOGL easy, since compatible
  - ..

Benefits of (2)
  - allowing all GLEventListener impl. use the new SWT GLCanvas, via it's GLAutoDrawable impl.
  - allows compatibility w/ all components using GLDrawable, GLAutoDrawable 

I guess both goals shall be impl. in the end.

Would you do & maintain it ?

+++

To enable me to pull your code, pls complete the following:
  - Add the JogAmp copyright notice as seen here [year 2011]:
        <http://jogamp.org/git/?p=jogl.git;a=blob;f=src/test/com/jogamp/opengl/test/junit/graph/demos/GPURegionNewtDemo01.java;h=5e0c266e65374b1d48bafc874891c9313a511198;hb=HEAD>

  - Transform your demo to a junit test and move it to the path
  jogl/src/test/com/jogamp/opengl/test/junit/jogl/swt/

  - Add a disclaimer to your SWT GLCanvas class, stating that this API is subject to change

Then I love to pull & merge your code, so we have some testing soon.

Sven, Wade, thanks for your feedback.

My current idea is to have two distinct classes:

swt.GLCanvas as a GLAutoDrawable
swt.legacy.GLCanvas as a drop-in replacement of eclipse's

but I'm not entirely resolved. Again, feedback is welcome.

Right now I'm studying the GLAutoDrawable awt implementation. It's all new stuff for me, so I'll probably need to ask you some clarifications.

I'll keep you posted.

I've started the implementation of the GLAutoDrawable-based SWT-GLCanvas.

https://github.com/carlo-salinari/jogl/commit/b3c2cfc3087a80b1dfd1f64fc8e57e6374f6a2ba

Most of it is cut-n-paste from awt.GLCanvas.

My understanding of the threading-model/locking issues is still fuzzy, and in particular I don't fully understand what's going on in awt.GLCanvas.display() (and if I have to replicate it).

If someone could give me some directions for methods:

display()
destroy()
reshape()

I think the new class would become usable pretty soon.

Sorry Carlo, I'm not too familiar with GLAutoDrawable, since I've mostly used pure SWT in the past.

I've made some little progress.

legacy.GLCanvas is now a drop-in replacement for org.eclipse.swt.opengl.GLCanvas (though GLData is ignored for now). Moreover legacy.GLCanvas is now a subclass of jogamp.opengl.swt.GLCanvas, so it is also a GLAutoDrawable and its implementation is much cleaner.

This at least shows that the context-creation part of swt.GLCanvas is working, but for the moment none of the GLAutoDrawable functions/characteristics are exercised nor tested.

The bottom line is: you can use legacy.GLCanvas in your eclipse app, but don't rely on jogl autodrawable features yet.

https://github.com/carlo-salinari/jogl/commit/47527f0997869bedcb7ce4f8887e234e9a274ad6

https://github.com/carlo-salinari/jogl/commit/93b66c67382c429aa70c0ad5cec1f50d386c86e1

> https://jogamp.org/bugzilla/show_bug.cgi?id=484
> 
> --- Comment #9 from Carlo Salinari <carlo.salinari@gmail.com> 2011-07-25 17:45:36 CEST ---
> I've made some little progress.
> 

Great !

BTW .. your idea w/ legacy vs 'real' is a good one IMHO.

> legacy.GLCanvas is now a drop-in replacement for
> org.eclipse.swt.opengl.GLCanvas (though GLData is ignored for now). Moreover
> legacy.GLCanvas is now a subclass of jogamp.opengl.swt.GLCanvas, so it is also
> a GLAutoDrawable and its implementation is much cleaner.

sweet. especially it allow the 'real' one to be clean off the legacy, nice.

> 
> This at least shows that the context-creation part of swt.GLCanvas is working,
> but for the moment none of the GLAutoDrawable functions/characteristics are
> exercised nor tested.

fair enough.

you could just test the GLAutoDrawable stuff, with plugging in an existing GLEventListener,
e.g. the infamous gears :)

> 
> The bottom line is: you can use legacy.GLCanvas in your eclipse app, but don't
> rely on jogl autodrawable features yet.

got it :) 
it's great.

IMHO you could 

  src/jogl/classes/jogamp/opengl/swt/legacy/LegacySWTGLCanvasInterface.java

leave as 

  src/jogl/classes/jogamp/opengl/swt/legacy/SWTGLCanvasInterface.java

since the semantics of 'legacy' are in the package name already.

3 files looks nice and clean.

+++

before we merge pls do the following ..

(1) file system 

move the  demo

  src/jogl/classes/jogamp/opengl/swt/legacy/Snippet209.java

at least to

  src/test/com/jogamp/opengl/demo/swt/Snippet209.java

if you don't want to make it a junit test and place it under

  src/test/com/jogamp/opengl/test/junit/jogl/swt/TestSWTSnipper209.java

  (that way it would be picked up by the right junit test launcher (SWT)


(2) copyright header

please add the jogamp copyright header as mentioned, thx.


+++

When merging and having time, I will look into the detail, while testing.

ofc .. I can complete things and help as well, np

Thank you very much Carlo

I've added a test case for swt.GLCanvas (GLAutoDrawable) as TestSWT03GLn. Problem is: it fails miserably. Actually, I haven't looked much into it, I just monkeyed around merging TestAWT01GLn (Gears) and TestSWT01GLn (Shell creation etc.).

For one, I don't understand where swt's display.readAndDispatch() call should be placed.

I've added the copyright headers and made the small fix you suggested. See if you like it.

Ah, no need to thank me: you did the heavy lifting (SWTAccessor etc.), I just filled in the blanks.

I'd like to see it work as a GLAutoDrawable now though. :-)

How does it work: should I make a new pull request, or is the old one still on, or it doesn't matter anymore?

Hi Carlo,

sorry, I have missed your last comment here.
And since I didn't got a new pull req .. ahem, I missed it.

So, you think I may just check your repo and pull .. ?
Shall I just try to clean up things if I see them, 
or do you prefer me to discuss it here 1st ?

Don't know how my schedule is for SWT this week .. 
but some time soon I hopefully have 1-2 days for it
and it should take much longer I hope.

Thank you for your work.

Cheers, Sven

No problem Sven.

Go ahead, pull the repo and make the gears fly :-).

Merged and applied minor changes and synced w/ latest JOGL changes plus added unit test.

One bug: Impl. still requires AWT threading. In AWT headless mode, a 'wrong thread' exception is thrown.
This is commented in GLCanvas and needs to be fixed to work w/ headless JVM.

The method runInGLThread(..) needs to be adapted to fix this issue.

Very good work!

The headless mode exception (see example below) appears to be due to a change in the default threading mode from AWT to Worker (which makes sense given that the AWT thread is disabled), and the SWT GLCanvas is incorrectly attempting to access certain state that should only be read from the SWT thread.  I'll have to peruse the SWT docs to see if there is a way to get this information from outside of the SWT thread, or implement store and update functionality since we probably don't want to block the GL worker and wait for a synchronous response from the SWT threat (e.g. Display.syncExec()).


Caused by: org.eclipse.swt.SWTException: Invalid thread access
	at org.eclipse.swt.SWT.error(SWT.java:4282)
	at org.eclipse.swt.SWT.error(SWT.java:4197)
	at org.eclipse.swt.SWT.error(SWT.java:4168)
	at org.eclipse.swt.widgets.Widget.error(Widget.java:466)
	at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:404)
	at org.eclipse.swt.widgets.Composite.getClientArea(Composite.java:593)
	at mil.afrl.rrs.ifsb.acesviewer.jview.GLCanvas.getWidth(GLCanvas.java:472)
	at mil.afrl.rrs.ifsb.acesviewer.jview.GLCanvas$2.run(GLCanvas.java:101)
	at jogamp.opengl.GLDrawableHelper.invokeGL(GLDrawableHelper.java:398)
	at mil.afrl.rrs.ifsb.acesviewer.jview.GLCanvas$3.run(GLCanvas.java:112)
	at jogamp.opengl.GLWorkerThread$WorkerRunnable.run(GLWorkerThread.java:244)
	at java.lang.Thread.run(Thread.java:679)

I sent a pull request (#43) that fixes the exception, however there may be a design flaw with the SWT GLCanvas' handling of JOGL's threading policy in this situation, because the default behavior should probably be to run in the SWT thread.

ThreadingImpl.getMode() reports ThreadingImpl.WORKER by default when java.awt.headless mode is activated.  In an effort to respect an explicitly (user) specified threading mode, the SWT GLCanvas treats this differently than if the mode was set to AWT.  The SWT GLCanvas treats 'AWT' mode as 'use the native windowing system's threading model; i.e. use the SWT thread for rendering.  The AWT/SWT mode is preferable to the Worker mode in most circumstances because rendering, reshapes, etc. will occur synchronously with the rest of the UI updates, which was one of the main reasons that we wanted a native SWT GLCanvas in the first place (e.g. rather than using the SWT_AWT bridge).

Maybe we need a way to differentiate between an explicit user request for the threading policy, vs. using the default policy?  I could just check the system property ('jogl.1thread'), but that seems messy and redundant.

You cannot get this information from another thread, calling org.eclipse.swt.widgets.Composite.getClientArea() will only succeed if done on the SWT current display thread. Why not calling it earlier when you have an opportunity of being on the SWT thread? Maybe my suggestion is naive...

(In reply to comment #17)
> You cannot get this information from another thread, calling
> org.eclipse.swt.widgets.Composite.getClientArea() will only succeed if done on
> the SWT current display thread. Why not calling it earlier when you have an
> opportunity of being on the SWT thread? Maybe my suggestion is naive...

I realized this fairly quickly, and just store/update the rectangle in a volatile field inside of GLCanvas each time it changes.

(In reply to comment #18)
> (In reply to comment #17)
> > You cannot get this information from another thread, calling
> > org.eclipse.swt.widgets.Composite.getClientArea() will only succeed if done on
> > the SWT current display thread. Why not calling it earlier when you have an
> > opportunity of being on the SWT thread? Maybe my suggestion is naive...
> 
> I realized this fairly quickly, and just store/update the rectangle in a
> volatile field inside of GLCanvas each time it changes.

Your fix will work whatever the thread policy we choose, it's ok for me.

<https://jogamp.org/chuck/job/jogl/645/label=macosx-10_6-x86_64-nvidia/testReport/>

<https://jogamp.org/chuck/job/jogl/645/label=macosx-10_6-x86_64-nvidia/testReport/com.jogamp.opengl.test.junit.jogl.swt/TestSWTJOGLGLCanvas01GLnAWT/testA01GLDefault_2/>

So on both arch's (32 and 64 bit), 'wrong thread access' still occurs.
For sure this is related to OSX special App thread, where AWT EDT just is not enough.

All SWT tests on that platform:
<https://jogamp.org/chuck/job/jogl/645/label=macosx-10_6-x86_64-nvidia/testReport/com.jogamp.opengl.test.junit.jogl.swt/>

We currently don't have a 'TestSWTJOGLGLCanvas01GLn' ie. running without AWT == headless,
which would be nice as well - even though this won't be the default environment though.

To finalize SWT support, IMHO this should be fixed. Then we can boldly make that statement.

Any chance somebody here wants to finish it?

A cursory examination of the exception with the fact that this is only failing on Mac indicates that this is an SWT issue, most likely an incorrect use of SWT in the test, or because SWT on mac requires an additional JVM flag to function correctly ('-XstartOnFirstThread', see http://www.eclipse.org/swt/macosx/).  I have had developers run into the second problem, but I am not sure whether this is the precise exception that occurs when the JVM flag is missing (I don't have easy access to a Mac).  If this is the problem, then the build might need to be changed to include the flag when running tests on Mac.  I'll take a closer look, but I have no direct means to test this.

WRT -XstartOnFirstThread, this Eclipse bug describes why it is needed and the efforts underway for removing the dependency.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=211625

Closing this feature request / enhancement, since we have 2 path of hooking
up to SWT. We may discuss further enhancements via new bug reports / requests.

Sorry for updating this issue so late.

+++

<http://jogamp.org/git/?p=jogl.git;a=commit;h=7bb5885fc3a904f49e22f0c8cbf747d9b189a7ba>

    SWT Update: SWT GLCanvas creates lazy when resource is ready; 
    Create new NewtCanvasSWT allowing to parent NEWT windows natively.
    
    SWT GLCanvas creates lazy when resource is ready
      - Ensures drawable and context are created when size > zero and native visualID is valid.
        The latter is platform dependent.
      - Note that you cannot utilize custom GLCapabilities w/ this one,
        since the configurations is already realized - use NewtCanvasSWT.
    
    Create new NewtCanvasSWT allowing to parent NEWT windows natively:
      - Similar to NewtCanvasAWT
      - Allows attaching / detaching NEWT windows
      - Allows using custom GLCapabilities
    
    NewtCanvasAWT: Public setNEWTChild(..) fixed
    
    Added test cases for the above - tested on Linux, OSX and Windows w/ SWT
    
    Note: As usual for OSX, add -XstartOnFirstThread
    
    Details:
    
    - NEWT Display has new method: 'EDTUtil setEDTUtil(EDTUtil)'
      allowing to set a custom event dispatch utility.
      We use this to set our SWTEDTUtil for using NEWT w/ SWT
      complying w/ SWT threading constraints.

Closing this feature request / enhancement, since we have 2 path of hooking
up to SWT. We may discuss further enhancements via new bug reports / requests.

Sorry for updating this issue so late.

+++

<http://jogamp.org/git/?p=jogl.git;a=commit;h=7bb5885fc3a904f49e22f0c8cbf747d9b189a7ba>

    SWT Update: SWT GLCanvas creates lazy when resource is ready; 
    Create new NewtCanvasSWT allowing to parent NEWT windows natively.
    
    SWT GLCanvas creates lazy when resource is ready
      - Ensures drawable and context are created when size > zero and native visualID is valid.
        The latter is platform dependent.
      - Note that you cannot utilize custom GLCapabilities w/ this one,
        since the configurations is already realized - use NewtCanvasSWT.
    
    Create new NewtCanvasSWT allowing to parent NEWT windows natively:
      - Similar to NewtCanvasAWT
      - Allows attaching / detaching NEWT windows
      - Allows using custom GLCapabilities
    
    NewtCanvasAWT: Public setNEWTChild(..) fixed
    
    Added test cases for the above - tested on Linux, OSX and Windows w/ SWT
    
    Note: As usual for OSX, add -XstartOnFirstThread
    
    Details:
    
    - NEWT Display has new method: 'EDTUtil setEDTUtil(EDTUtil)'
      allowing to set a custom event dispatch utility.
      We use this to set our SWTEDTUtil for using NEWT w/ SWT
      complying w/ SWT threading constraints.

@Sven, are the capabilities you described in Comment 23 found in JOGL 2.0-rc10 or will I need to wait until rc11?

(In reply to comment #25)
> @Sven, are the capabilities you described in Comment 23 found in JOGL 2.0-rc10
> or will I need to wait until rc11?

Yes, they are. However there is another fix completing the new SWT EDT for NEWT:
  <http://jogamp.org/git/?p=jogl.git;a=commit;h=1b6593f973970ad00a0a0f08b56cc83501a55ad2>

I recommend to test the latest aggregated build as announced in the forum/mailinglist:

+++

Please test using this latest aggregated build:
  <http://jogamp.org/deployment/archive/master/gluegen_586-joal_355-jogl_803-jocl_672/archive/jogamp-all-platforms.7z>

Jenkins page of this JOGL build:
  <https://jogamp.org/chuck/job/jogl/803/>
Tip is git sha1 608a8aaee0da2d32eeb6f9b4efe9c34013efda31 branch master.
  <http://jogamp.org/git/?p=jogl.git;a=commit;h=608a8aaee0da2d32eeb6f9b4efe9c34013efda31>

A signed test version for Applets etc is avail here:
<http://jogamp.org/deployment/archive/master/gluegen_586-joal_355-jogl_803-jocl_672-signed>

+++