Community
Participate
Working Groups
It would be nice to be able to use JOGL to draw to an SWT GLCanvas.
Created attachment 27685 [details] Code example using SWT_AWT
Comment on attachment 27685 [details] Code example using SWT_AWT A temporary way of doing it.
Billy, any news on this front? JOGL recently released betas of their JSR-231 reference implementation which is supposed to be toolkit agnostic. I guess now is the time to give feedback to these guys whether it will work with SWT or not.
Created attachment 28912 [details] SWT-JOGL interop sample Here's something on the topic of JOGL<->SWT interop I was able to quickly slap together for a few hours. Note: I've tested it only on Windows, it kinda works, it is unfinished and it has tons of bugs. Oh, and it is "dirty". more on this below. Prerequisites: - Latest SWT integration build: swt-I20051025-0800-win32-win32-x86.zip - The first JSR-231-compliant JOGL beta; how to get it is written here: http://www.javagaming.org/forums/index.php?topic=11280.0 The demo (SWTGears) just does a minimal port of the Gears demo available in the JOGL distribution to SWT/GLCanvas. I'll express my first impressions reg. SWT/JOGL integration in a separate comment.
My comments: 1. JSR-231 seems to be a specification of interfaces or abstract classes that everyone can implement in order to have JSR-231-compliant OpenGL support. 2. It is not 100% toolkit agnostic: - AWT-specific stuff surfaces here and there, like GLAutoDrawable (uses AWT event classes), GLCanvas (based on AWT Canvas), GLDrawableFactory (exposes AWT GraphicsConfiguration), GLCanvas, GLJPanel and whatnot; these should be probably moved to javax.media.opengl.awt, as SWT obviously cannot implement these. - GLPBuffer extends GLAutoDrawable, which is AWT-specific (!!) - PBuffers (GLPBuffer) can only be created via GLDrawableFactory; as mentioned, some methods in GLDrawableFactory have AWT semantics 3. Using the reference implementation of JSR-231 (JOGL) in combination with SWT instead of reimplementing javax.media.opengl.GL from scratch seems like a good idea, for the following advantages: - JOGL will do the dirty job of providing working, standard, up-to-date javax.media.opengl.GL implementation (the toolkit agnostic thing) - JOGL will also provide PBuffer support (again toolkit agnostic?) - SWT will do the GL context management, i.e. it should provide (via JOGL Adaptor or something) implementations for javax.media.opengl.GLDrawable and javax.media.opengl.GLContext, by delegating to the public API of org.eclipse.swt.GLCanvas (if possible), or to its internals. - Note that providing *public* API in SWT (or in SWT-compatible JOGL adaptor) to get GLDrawable/GLContext may not be strictly necessary, as org.eclipse.swt.GLCanvas already has the most important functionality provided by these, yet these are amongst the JSR interfaces/abstract classes, so public implementations of these should be probably available? 4. However, the current JOGL codebase has the problem that the *implementation* of javax.media.opengl.GL (com.sun.opengl.impl.GLImpl) is also not completely separated from AWT: - The JOGL.DLL has hard dependency on JAWT, and one needs to load JOGL.DLL *and* JAWT.DLL; for JAWT.DLL to be loaded correctly, java.awt.Toolkit.getDefaultToolkit() should be called first which is not nice (Billy, will this run the AWT message pump on MACOSX?) - Using com.sun.opengl.impl.GLImpl kind of drags a dependency on com.sun.opengl.impl.GLDrawableImpl, so one has to implement GLDrawableImpl- based derivative, if for nothing else, then to pass to GLImpl constructor.. 5. In a perfect world: - One should be able to use JOGL with SWT; SWT itself should not depend on any interfaces/classes in javax.media.opengl. Instead, additional "adaptor" class can be devised, that "knows" about SWT GLCanvas and about JSR javax.media.opengl and can bind the two - JOGL should not load JAWT/call AWT stuff unless the user code uses AWT- specific JSR classes, like GLAutoDrawable, GLJPanel, etc. - com.sun.opengl.impl.GLImpl should probably take something simpler than GLDrawableImpl.. 6. Finally - Take this all with a huge grain of salt, I only know SWT and AWT; OpenGL is relatively new to me, and probably I have no idea what I'm talking about..
New to the Eclipse community but not to JOGL. I'm Mithrandir in the above linked JGO forum thread. I've been working on a proper native port of JOGL to SWT for the last couple of days (it's a paid contract by one of our clients). In addition, my company is involved in the JSR group for this. Wanted to drop in some notes in addition. The DrawableFactory APIs are generally not much of an issue. The IBM folks on the JSR are pushing for some extra changes there to remove more of the AWT dependencies. That said, the way that it is expected non-AWT code would work with the factory is through the alternate createGLDrawable() method. I've already made sure that some of the issues listed in comment #6 have been passed back to the JSR team. In addition, you may want to track, or add to the following thread that I've just started over on JGO. http://www.javagaming.org/forums/index.php?topic=11316.0 The JSR team aren't likely to read this bug report, but the main Sun developer definitely tracks the JGO forums. Your issues would definitely be best posted there so that it's quickly visible to them.
Mithrandir! Glad to have you aboard. I have heard that JOGL is supposed to be window toolkit agnostic. I can't think of a better way to test/prove this than to port it to SWT. There are good reasons why there should be no references to AWT classes in JOGL. On the Macintosh, there is only a single GUI thread per process. Touching AWT attempts to start another one and this doesn't work with SWT. See bug 67384 for the gory details. Good luck. Please enter bugs for any issues you have with the OpenGL support in SWT.
More updates. Have sent a revised GLDrawableFactory proposal off to the Sun people. This would eliminate the use of AWT-specific classes at that point. The sticking point remains with the combination of GLAutoDrawable, ComponentEvents and GLPbuffer. There's no way that GLAutoDrawable should extend ComponentEvents, but the Sun enginneer responsible is sticking to his guns on that one. It's going to need a lot of work to convince him otherwise. It's going to take more than just me jumping up and down to get this changed. Adapting in to the swt.GLCanvas shouldn't be that hard. I've looked around at most of the code and it should be fairly easy to blend them together. The question, for you here, is what form should the swt.GLCanvas take - should it use the GLEventListener callback system that is already in the JSR design or stick to something more SWT-like? FWIW, I don't see there being any point in trying to use GLCanvas and GLJPanel from the core implementation. What I'm aiming for is to have the GLDrawableFactory just as easily generate an instance of swt.GLCanvas that implements either GLDrawable or GLAutoDrawable as it currently does the AWT versions. I don't think it's going to be possible to reuse all of the reference implementation code, but much of the basic framework can be used. There's way too much spaghetti code going on down in the impl layers to really make insertion of SWT handling code easy, without tripping the AWT event mechanism. Note that in the JGO thread above, that making use of the existing PBuffer implementation classes uses the native AWT code to lock the surface on at least one platform. We'll have to start again from scratch, but pull in as much of the existing code as possible. Finally, is there somewhere other than this bug report that we could discuss some of this from a design and implementation perspective? Out on the news server, the discussions are going to get drowned in the noise. A quieter dev email list perhaps?
Thanks Justin for the update. For design discussion, while it may seem like noise, we prefer to have the discussion in the bug system since people can watch issues they're interested in by adding themselves to the CC, the discussion is easily searchable, etc. Regarding the GLCanvas, my aim with the OpenGL support in SWT now is that we have a core GLCanvas which acts as an interface to AGL/WGL/GLX, and then any JOGL support is built on top of that. So ideally, the GLCanvas from SWT wouldn't implement the GLDrawable interface, it would be a JOGLCanvas above it. The thing I think would be really useful would be a way to just get a GL instance from somewhere, along with a method to get a new one if I change contexts (for Windows where the function pointers change). I think just getting that first would be really useful, and then worry about the rest of the API :)
I'm also on #eclipse-dev on irc.freenode.net for real-time discussion.
OK, that makes sense, and is somewhat like the AWT equivalents. How about the GLAutoDrawable style handling - a callback system much like the GLUT also uses? This automatically deals with the context changing and notifications to the end user. In some of the private discussions with the JSR people, they seem willing to move a bit with the GLDrawableFactory class. Lots of wildly different suggestions on both sides. Hope to come to some reasonable conclusion today. Since you are discussing a JOGLCanvas, would you expect to produce instances of this through the GLDrawableFactory or through direct instantiation? Ideally I'd like to have it go through the factory methods as that means our toolkit and scenegraphs that layer over the top don't need to be too different in code structure between the AWT and SWT versions.
I now have a basic GLCanvas implementation going for Win32. This just repaints by having an external thread grab the GLContext and do an endless makeCurrent()-glFoo()-release() call. There's no paint listener callbacks. I'd like to include some sort of GLAutoDrawable capabilities. In the AWT version, the provided GLCanvas implements the GLAutoDrawable interface and then takes care of all the callbacks as needed (effectively it is a drawable that wraps the real drawable). Thoughts on a prefered design?
Justin, when you say a basic GLCanvas implementation, to be clear, is this implemented on top of the SWT GLCanvas from 3.2M3?
No, a separate canvas class. While you could pass the GLDrawableFactory an instance of the org.eclipse.swt.opengl GLCanvas and have JOGL draw to that, you don't need to. At the lowest level you can just pass it a straight random SWT Canvas and it will be able to paint to that. I also have a convenience class that does all this work already that instantiates the JOGL factory, fetches a drawable and creates a GLContext to use. If you pass my drawable factory an instance of the SWT GLCanvas, I'll grab the GLData from it, convert that to the JSR GLCapabilities equivalent and then continue on treating that canvas as just a raw Canvas. The existing GLCanvas in SWT is, effectively, not useful for the JSR code. The JSR code assumes that it is taking care of all the GLX/WGL/etc intialisation process that is currently being done in the constructor of the various platform-dependent implementations of GLCanvas. The SWT version of GLCanvas itself doesn't really do anything useful as a standalone item either. There's makeCurrent calls, but no context or GL interface class to use. You end up needing some other abstraction from this. If you want to do that, then the existing RI of JSR-231 can handle the code you need without any further work. There's a method call in GLDrawableFactory named createExternalDrawable() that will already work with the SWT GLCanvas code (excepting Mac-AWT interaction problems). Even then, the GLCanvas makeCurrent/swapBuffers calls are going to be problematic when you have the same calls on the JSR GLDrawable/GLContext classes. Multithreaded access to these, since they are coming from different code, are going to be extremely problematic. Given the nature of the SWT GLCanvas, I just don't see it being useful with the JSR code. I was doing some code that was creating a separate GLDrawable object that had it's makeCurrent and swapbuffer calls do calls back to the SWT GLCanvas, but because they were using different wrappers for WGL/GLX etc, I was running into several different native code crash issues. I suspect that's because they had different ideas about which window native handle each was using and the different code tromping on each other. In the end, the cleanest code path for me to implement was to start with the JOGL RI and take out the bits that were AWT-specific, replacing them with SWT-specific code.
That makes sense although it does break the intention of the GLCanvas widget in SWT, which was to act as a platform for any OpenGL binding, including JOGL. Also, I am concerned about how this will work under Linux, where you need to choose the GL capabilities before you create the X window for the widget, so if you are drawing on an existing Canvas you either need to live with its GL capabilities, or create a subwindow. What were your thoughts here? I'd be interested in exploring the native crashes you were seeing, or what other bad interactions there were between the JOGL vs SWT abstractions, but if you're really convinced this is the wrong approach then don't worry too much about it.
Bah, wanted to add more... There's nothing stopping me from going back and completely implementing a separate version of the JSR interfaces using the org.eclipse.swt.internal.opengl.* packages but that's going to take a lot more work to do. My first aim is to get drawing happening as fast as possible. The RI code does almost all the good work for us, including automatically generating all the GL class calls. It is also doing a lot of really funky under the covers work for the Pbuffer code. I'm pretty sure it's going to be a heck of a lot more work than just doing a global search and replace of com.sun....GLX/WGL/etc for the SWT versions of the same.
(In reply to comment #15) > That makes sense although it does break the intention of the GLCanvas widget in > SWT, which was to act as a platform for any OpenGL binding, including JOGL. I really don't think that's a practical goal considering that it is going out of it's way to already do a lot of the GL initialisation before the external toolkits start up. > Also, I am concerned about how this will work under Linux, where you need to > choose the GL capabilities before you create the X window for the widget, so if > you are drawing on an existing Canvas you either need to live with its GL > capabilities, or create a subwindow. What were your thoughts here? AWT is faced with the same issue. Right now I haven't done any work on the X11 code other than pull the AWT code out of it. Since my primary dev box is a Windows machine, I'm working out the large-scale issues there and then I'll swap desks and grab the Mac and linux boxes there. > I'd be interested in exploring the native crashes you were seeing, or what > other bad interactions there were between the JOGL vs SWT abstractions, but if > you're really convinced this is the wrong approach then don't worry too much > about it. Ya. See my other comment that looks like we crossed paths here. I think it can be done, but it would mean a wholesale reimplementation of the JSR APIs, not just a light tweaking of the existing RI, which is what my current efforts are focussed on.
What GL initialization are you worried about specifically? There are really two APIs, the platform-independent OpenGL API, and the platform/toolkit specific interface layer (WGL, GLX, AGL, etc). Given the interactions with the toolkits, this second layer I think needs to be a part of SWT, while the OpenGL binding clearly does not. PBuffers are a bit special I agree, but I think they're less important than the OpenGL binding, even more so now that FBOs are the new hot (platform-independent) thing. If there's a real need for PBuffer support then pushing that code into the SWT layer may be more appropriate. I agree that a wholesale reimplementation would be a bad approach.
(In reply to comment #18) > What GL initialization are you worried about specifically? All the process address table and extensions handling has been the biggest problem. This is being done internally by the RI with their wrappers to WGL et al. The problem is that I cannot get to those same objects at the SWT GLCanvas level without subclassing GLCanvas in a platform-specific manner so that I can include a public method for to grab the windowing system handle. That then defeats the purpose of just using the SWT GLCanvas as is. I recall there being a few other problems, but haven't played with that code for about a week, so I'll have to go back through my notes to find out what else was causing issues. Another minor issue is that the GLData class doesn't include the full capabilities of the post 1.1 OpenGL calls. The JSR equivalent also lists whether to request/require pbuffers and floating point buffers. > I agree that a wholesale reimplementation would be a bad approach. In the end, I think it will be cleaner code than some of the hacking I've had to do with the RI code. I'd like to probably head down that path at a later date. Doing so would make it much easier to include the code formally with the Eclipse project standard distributables.
Calling [wgl,agl,glx]GetProcAddress does not require anything from the window system. On Win32, function pointers for extension need to be stored per-context, but this is pretty easy to handle. I would expect that JOGL would have its own code to get any function pointers and this should work independent of the toolkit-specific code in SWT (see LWJGL for an example of how this can work). For OpenGL extensions which do have window-system specific parts, such as PBuffer support, I understand that this would require more work in the SWT code, but I thought this could happen here as needed rather than push more work down to the JOGL layer. Any required capabilities missing from GLData should just be added, remember that the 3.2M3 release of this code is just a milestone release and can still be changed.
Created attachment 30386 [details] Cheesy demo using createExternalDrawable Wow. We investigated using createExternalDrawable() and it seems to work great. The attached demo works on Win32 and GTK+, although it gave a "not implemented" exception on the Mac. This seems to prove that the JSR code can work fine with the SWT GLCanvas widget, and so I think this bug as titled should be closed or renamed. While it was apparent in comment #14 that this could be done, we hadn't quite clued in. Justin, what do you think is missing?
I added SWT snippet 209 to demonstrate using JOGL with SWT. See: http://www.eclipse.org/swt/opengl/ http://www.eclipse.org/swt/snippets/#opengl
(In reply to comment #21) > This seems to prove that the JSR code can > work fine with the SWT GLCanvas widget, and so I think this bug as titled > should be closed or renamed. Disagree mildly there because we should be able to use all the different JOGL APIs for context creation etc. Also, I don't think you've tested pbuffer support yet that way, which could lead to a lot more funky code behaviour. I'd like to keep it open until I at least have fully working code of a complete implementation. > While it was apparent in comment #14 that this could be done, we hadn't quite > clued in. Justin, what do you think is missing? Right now I have running code for most things. The one area I'm faced with an issue is doing something similar to the snippet 209 but using the createGLDrawable(Object) method on GLDrawableFactory. If multisampling is enabled it all works fine. However, if I turn it off I'm running into one of the problems alluded to above about trying to render to an arbitrary SWT Canvas. Basically I need an API to get to the underlying window handle (HDC) from that arbitrary canvas. Things are failing when I'm trying to fetch a pixel format descriptor because wglGetCurrentDC() doesn't have a valid context to use yet. Chicken and egg situation where you need a pixel format chosen before you make current but need to be in a current context so you can fetch the drawable handle. The SWT internal classes, particularly OS aren't exactly well documented. Any suggestions on how to work around this issue of fetching a given arbitrary Canvas's window handle from outside the class?
I see pbuffers as something that should first be added to the SWT API, if it is really required. The problem with pbuffers is that the implementation is very platform and driver specific, and my understanding is that this is what the GL_EXT_framebuffer_object extension is solving, so maybe pbuffers are not worth supporting unless there is a compelling reason. Drawing on an arbitrary SWT Canvas will be tricky on other platforms, but may be reasonable on Win32. The handle field on each Control in SWT is an HWND on Win32. The methods in OS are simply from the Win32 API, you can use MSDN to see what they do and how to use them. Also, see the implementation of GLCanvas in SWT to get an idea of how to get an HDC.
Created attachment 30511 [details] Example using a generic SWT Canvas with JOGL This shows how to use the JOGL API with any generic SWT Canvas. It is implementation independent, except for the setting of the JSR system property that tells the code which class to load as the implementation of the factory. If you wish to run the demo code completely as-is, you'll need to download the JOGL implementation from http://opengl.j3d.org/. As of the time of writing this example, you cannot download the code. I'll be putting it up there within the next day or two.
Initial code is now up to play with. Head to http://opengl.j3d.org/swt/downloads.html to grab the code and have fun. You'll need to make sure that you don't have the existing JOGL RI findable in your classpath, and use the one that comes with the download. For Win32 only right now. Other platforms coming shortly, but I want to try out a couple of our other projects (Aviatrix3D scene graph and Xj3D X3D loader) first and see whether we break anything. Those projects stress JOGL in unusual ways, so should be a good test of this work. I've not yet tested it with anything other than very basic interactions.
Where's preview when you need it :) Got the URL wrong in the last comment... http://opengl.j3d.org/swt/download.html Grrrr.....
Hi guys - I lead a team at NASA that's writing Eclipse RCP applications to operate Mars rovers and landers. One of the areas that we've been struggling with has been SWT's support for 3D graphics, so I'm ecstatic to see so much progress on JOGL support. I think we're likely to be an early user of this. I'm very interested to hear whether Aviatrix3D works on top of what you have so far.
Jeff, I've just a couple of minutes ago fixed the last bug in the Aviatrix3D handling of SWT. We're up and running quite nicely. I've not tried it within Eclipse yet, but as a standalone SWT app, it's working well (at least on Win32, other platforms not yet complete). No tarballs yet, but I think I'll put together a AV3D 2.0 beta 1 tarball in a few days for people to play with so they don't need to play with our CVS or build environment. If anyone is interested in playing before then, please fire me a private email to the address I used here.
New update on the Mac porting. I've run into quite a snag. SWT uses Carbon interfaces, while the JOGL RI uses Cocoa. Apple explicitly states in their interoperability guides that one cannot embed carbon widgets in cocoa windows, and vice versa. DOH! It appears that I'm going to have to write the Mac version from scratch rather than just making use of and tweaking the existing RI code.
I've just made public a new release of the SWT OpenGL work. This now correctly, natively supports OpenGL on SWT on Mac OS X as well as the other platforms. In the end I had to get quite a few changes made to GlueGen to support the requirements of AGL binding generation under the existing JOGL framework. That took its time to work through the system. As it is, we now have proper JOGL support with native SWT widgets as well as direct Eclipse plugin support. You can find out about the latest version (0.5) here: http://opengl.j3d.org/swt/ Right now I have just Win32 and OS X/PPC versions there. I do have a MacBook on its way to test the universal binary version. Once that is up I should be able to release a full universal binary version of the bindings. I'll also have Solaris/Sparc and Linux in both 32 and 64bit variants at the same time. I haven't extensively tested the OS X version yet. Some more work still needs to be done, particularly in the area of pBuffer handling. However, I've been running the standard pipeline with a lot of really heavy content driven using our higher level toolkits. Stuff upwards of 200K polygons and multilayered composited scenes run without hitch. The downloads are already configured to be an eclipse plugin so it all should Just Work(TM). I've followed the same structure as SWT using a fragement host and extension to provide the basic definition and then the native code interface for each platform. For interest, our higher level toolkits (Aviatrix3D Scene graph and above) also needed the OpenAL bindings as Eclipse plugins too, so I took the standard JOAL downloads and refactored into versions that are suitable for direct plugin usage if you desire direct spatialised audio support. The link can be found on the above page. Finally, the ExternalDrawable demo attachment included on this bug report is now invalid. The setCurrent() method on GLContext is no longer public (it went protected about 3-4 months ago). I've yet to work out how to get the external Drawable stuff to work now with SWT as there seems to be some sort of chicken and egg problem with the context creation and native widget handling. The JOGL code now states that it requires the widget to have an already running and current OpenGL context for it to connect to. In the external drawable example, the timing is such that there is nothing to play with at the time the external drawable is fetched, and it fails with some internal exception.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
