Resurrect the native SWT codebase?

[STRESS]

I've got a question concerning the SWT directories in the source tree from a quick glance I noticed this looks like a native SWT / JOGL backend but it is not actually build in the normal release I assume that work on it has sort of halted? I am asking because I use jReality in context with an Eclipse RCP environment and Eclipse RCP is unfortunately all SWT/JFace. There is the Swing<->SWT bridge which I am currently using but there are known serious stability issues with that under Redhat Enterprise Linux which is one of the main target OS platform my application is running on besides Windows. So I wonder if anybody on the jReality team can give me some estimates how much effort I would need to spend to get that SWT backend working again or is that hopelesly outdated and it is not worth to spend anytime on it?

[steffen]

Well it is pretty old, but I think it should be possible to get something similar working. No idea how SWT has changed in the meantime... The SWTViewer is more or less a copy of (a very old version of) JoglViewer, using an external GL Context. There is also an example in src-example/de.jreality.example.SWTExample using it. This was more or less a proof of concept, showing that the jogl viewer also works with SWT.

If you want to look into it, it probably makes sense to start with the current version of JOGLViewer and apply the changes from SWTViewer to it. Please let me know how this is going. It would also be interesting to know how one has to configure the eclipse project to get it working, I cannot remember any more...

[STRESS]

Well it is pretty old, but I think it should be possible to get something similar working. No idea how SWT has changed in the meantime... The SWTViewer is more or less a copy of (a very old version of) JoglViewer, using an external GL Context. There is also an example in src-example/de.jreality.example.SWTExample using it. This was more or less a proof of concept, showing that the jogl viewer also works with SWT.

Hmm I had a look at that example I am seriously doubting that this can work in the current form it exists. Since it only initializes the viewer object in the non-SWT branch but uses it afterwards in either branch. That can't really work. Or am I missing something here ???

If you want to look into it, it probably makes sense to start with the current version of JOGLViewer and apply the changes from SWTViewer to it. Please let me know how this is going. It would also be interesting to know how one has to configure the eclipse project to get it working, I cannot remember any more...

Hmm jogl.Viewer extends AbstractViewer and AbstractViewer has some stronger ties to AWT objects in general it uses lots of AWT Image objects and events. So coming from that direction will probably not that easy. :?

[steffen]

I am seriously doubting that this can work in the current form it exists. Since it only initializes the viewer object in the non-SWT branch but uses it afterwards in either branch. That can't really work. Or am I missing something here ???

True. But there is a line commented out, which made the connection out of the branch:

Code: Select all

//      viewer = new ToolSystemViewer(swtViewer);

ToolSystemViewer was refactored away once, I think there is now a static method to create a tool system for a viewer. Anyway, on the SWT viewer you can render manually.

Hmm jogl.Viewer extends AbstractViewer and AbstractViewer has some stronger ties to AWT objects in general it uses lots of AWT Image objects and events. So coming from that direction will probably not that easy.

Yes, AbstractJoglViewer is the right class to start with. I have just looked into the code and the AWT references are not that bad. They actually mark where to replace code for the SWT Viewer... It would be great to split the AWT apart from AbstractJoglViewer into AbstractAWTJoglViewer extends AbstractJoglViewer. Then SWT and AWT can have a common base class.

[STRESS]

Hmm jogl.Viewer extends AbstractViewer and AbstractViewer has some stronger ties to AWT objects in general it uses lots of AWT Image objects and events. So coming from that direction will probably not that easy.

Yes, AbstractJoglViewer is the right class to start with. I have just looked into the code and the AWT references are not that bad.

Well they are all over the shop the main problem is that a lot of the methods use GLAutoDrawable as parameter even further down in JOGLRenderer but GLAutoDrawable is an interface and the only implementation for GLAutoDrawable in JOGL as far as I can see are derived from AWT components, there are no SWT counterparts. Ahh the usual Java/OpenGL mess.

They actually mark where to replace code for the SWT Viewer... It would be great to split the AWT apart from AbstractJoglViewer into AbstractAWTJoglViewer extends AbstractJoglViewer. Then SWT and AWT can have a common base class.

Not sure how much would be actually left if you split these up!

[STRESS]

They actually mark where to replace code for the SWT Viewer... It would be great to split the AWT apart from AbstractJoglViewer into AbstractAWTJoglViewer extends AbstractJoglViewer. Then SWT and AWT can have a common base class.

I decided to go for a slightly different way I moved all the AWT references besides the BufferedImage offscreen bits (I have to look at this yet) out of AbstractViewer now into Viewer. And changed some methods into abstract methods. I think it makes more sense if both Viewers extend from AbstractViewer instead of putting another AbstractViewer layer inbetween. I would change Viewer to AWTViewer and add SwtViewer.

I managed to get something displayed by making a few changes in SwtViewer but there no Events are getting through yet not even the repaint / expose events from higher up. So I guess there is a lot of work to do in SwtViewer. I also need to find the hooks from higher up (ViewerApp) to when the actual the JOGLViewer is instanciated so I can create a SWT path there as well.

[steffen]

I decided to go for a slightly different way I moved all the AWT references besides the BufferedImage offscreen bits (I have to look at this yet) out of AbstractViewer now into Viewer.

You are right, I thought that also the GLJPanelViewer was derived from AbstractViewer, but it is not... Maybe Charles should comment on what the idea of AbstractViewer was.

I managed to get something displayed by making a few changes in SwtViewer

This is great news!

... but there no Events are getting through yet not even the repaint / expose events from higher up. So I guess there is a lot of work to do in SwtViewer. I also need to find the hooks from higher up (ViewerApp) to when the actual the JOGLViewer is instanciated so I can create a SWT path there as well.

I would like to look into that, guess it will be easy to get tools working again. But I am not familiar with SWT development, so maybe you can post the necessary eclipse settings... It would be great if we can revive the SWT viewer - I would love to have a HelloWorld Eclipse plugin as a tutorial (but I have no idea how it would work...)

[gunn]

GLJPanelViewer should be a subclass of AbstractViewer, not Viewer. I've changed that now and checked the tutorial example GLJPanelViewerExample to make sure it works as expected. It does. Don't know how that happened. I guess I started GLJPanelViewer by subclassing Viewer, realized it would be smarter to have a common abstract superclass for Viewer (using a GLCanvas) and GLJPanelViewer (using a GLJPanel), did the right thing for Viewer but forgot to go back and make the change for GLJPanelViewer.

The methods for rendering offscreen may seem a bit out of place in the Viewer class. The reasoning is as follows: the Viewer has an instance renderer of type JOGLRenderer, and this is used to do the offscreen rendering. Attempting to do offscreen renderer without an existing instance of JOGLRenderer would require initializing a new instance, which would then have to build the whole proxy scene graph for the JOGL backend once more. This seemed like a high price to pay for getting rid of these methods, so I've left them where they are.

[steffen]

Ok, so we need AbstractAWTViewer...

[STRESS]

Ok, so we need AbstractAWTViewer...

Hmm too late I already changed it I've got AbstractViewer, ViewerAwt and ViewerSwt. I also changed ViewerApp to AbstractViewerApp and made that AWT independent and moved ViewerApp to be the AWT implementation of AbstractViewerApp and added ViewerAppSwt to be the SWT counter part but only creating an instance of ViewerSwt not of the software or portal viewers.

I've come across one thing I don't really understand what is the purpose of SwtQueue? In the render() method of SwtViewer it gets an instance of that SwtQueue which then uses SwtViewer as runnable but creates a new thread and which then will call the run() method in SwtViewer, but that method checks if the currentThread is the same as the thread (because of the SWT/Native GUI thread restrictions) of it's canvas which it obviously will not be so it fails and raises an exception!

[steffen]

I've come across one thing I don't really understand what is the purpose of SwtQueue? In the render() method of SwtViewer it gets an instance of that SwtQueue which then uses SwtViewer as runnable but creates a new thread and which then will call the run() method in SwtViewer, but that method checks if the currentThread is the same as the thread (because of the SWT/Native GUI thread restrictions) of it's canvas which it obviously will not be so it fails and raises an exception!

I dont see where it would create a new Thread, it creates a "TrackedRunnable" that is executed in the SWT thread as far as I can see... I think we need some way of code sharing, I have written the code several years ago and it wasn't used much. Maybe you can send your viewer classes via email to me, and give some hints on how to setup the eclipse project.

[STRESS]

I dont see where it would create a new Thread, it creates a "TrackedRunnable" that is executed in the

Well if you look at the private constructor of SwtQueue it is generating a Thread and starts it. In it run method it is then generating a display and things like that.
I don't know whatever SwtQueue was meant to do it doesn't seem to work at all. Since the thread seems to be never the same one as the GLCanvas thread so I alway get InvalidStateException. You probably could fix this by not creating a new display (and shell?) yourself but using the display from the GLCanvas that would guarantee you are really on the same thread I assume but I am really not an expert on SWT myself.

I think we need some way of code sharing, I have written the code several years ago and it wasn't used much.

I am happy to share my changes with you. But I am not fully done yet I still have to get the events working fully. For doing so I noticed I have to make some slight changes to ToolSystemConfiguration as well to load a default SWT profile somehow. I got Left/Right/Middle MouseButton and Mouse move working by a quick hack but not MouseWheel I think the code isn't active in DeviceMouseSWT.

hints on how to setup the eclipse project.

Sorry I can't help you there :( since I am making the changes outside of Eclipse and use the ant building process right now. (However I had to make some modifications to build.xml) I never used the jReality eclipse project so far. I would have to look into that first. But personally I am not a big fan of Eclipse and it's project configuration, bundling and OSGI plug-in development system (looks overally complicated for something that should be really simple ) just I am forced to use it for the main project I am working on.

[STRESS]

Okay I think I got everything working now using native SWT GLCanvas, besides the offscreen rendering which I yet have to look into. I've attached a working screenshot in a RCP Plug-in without using the AWT/SWT bridge. At some stage I ran into some really strange problem under Linux. It seems to me that GLCanvas needs to have NO_BACKGROUND as style set when created otherwise the expose/repaint events cause some strange behaviours. I couldn't find any hint or documentation on this why this needs to be the case. SWT documentation as in general seems to be very sparse :( .

So if anyone is interested I am willing to post the code or make it available in other means. It could well conflict with some refractoring changes you guys might have done in the meantime.