Of course this had the result of breaking this feature, but with the very kind help of the JOGL devs, we were able to make it work again (the last fixes are still not in trunk, but should be shortly).
However, the discussion with the devs have opened a whole new world of possibilities. In short, the OpenGL rendering of the whole Swing /ARINC 661 hierarchy was only performed by creating an OpenGL texture and rendering it in the eternal OpenGL context, which was not very efficient and the graphic quality was not so good.
There is a mature project called GLJ2D which allows to draw (yes, really draw) efficiently in any OpenGL context. Our first tries with this code (which relies on JOGL of course) are VERY encouraging, which will allow people to use J661 embedded efficiently ikn any OpenGL context, for example in FlightGear ;)
Herve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The textured mode is working again, but now with the last autobuild version of JOGL, rather than JOGL 1.1.1.
The "direct" (no texture used, direct OpenGL orders using GLJ2D) mode begins to work in some simple use cases.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now everything is working well, even in the direct OpenGL mode, The rendering in an external OpenGL context is identical to the pure Java swing rendering. We still need to document this well (this is not really the case for now), and finish to add events hand;ling (it's in fact not very difficult).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are there any code examples illustrating how to make render a texture into a different GL context such as flightgear or some other software? What is needed to support j661?
thank you
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Arghh sorry for y lack of answer, I did not see this last question because I forgot to monitor this thread. The only requirement is to have a Java 6 or Java 7 JDK installed on the platform (n fact it it not necessary to formally install it, having it put somewhere on the PC or Mac is enough).
You should also have the OpenGL headers because you will need them on the C or C++ part of your code. This wiki article here shows how to perform the embedding: http://sourceforge.net/apps/mediawiki/j661/index.php?title=Embedding_the_server. We support the ability to define more than one context meaning that you also can embed more than one display in your C application.
I will update the "native" part of the binary release to have a complete working example of a C app example for that. It might not work anymore since we updated a lot of things since the time I created the current version. I might also put it in a contrib release rather than in the core release, which will make possible to add more things to flesh out the example itself.
Our implementation work well, the current implementation take approximately 20 ms to render a whole complex display including a working Map. Also it respond t user events like clicks or drags coming from the C code.
Hervé
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You could use the same method to generalize the CDS and transform it into a different target language, which does not require a runtime environment (unlike Java or C#) -for example C++, ObjC, C or even SPARK/Ada.
From an implementation point of view, the transformation could always require a struct/class to provide a certain platform-specific interface (methods), to deal with platform differences (setPixel primitives, mouse handling, networking etc).
That would make it possible to support different backends (OpenGL, DirectX, GDI, X11)
By convention, you could also make this GPL so that people are bound to the terms of the GPL, but your original Java CDS code could then be more easily used on other platforms.
This would also ensure that people would contribute their own language/platform interfaces.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your idea is good, but the only problem is the amount of work it would need to be able to do this.
However, I think one (small) part of this task has already been performed some time ago, on the J661 Java CDS. When I tried to port J661 to Android, I discovered that there were a LOT of differences between Oracle Java and Android's Java. There are so many things in Android which are different (IMO they are worse, but it's just a personal opinion), that I had to abstract a lot of constructs which I took for granted that it ended with (it's the frodo branch) two parts : the generic one, not tied to any graphics or other specificities, and working in both the Oracle JRE and Android, and a (pluggable) other one which contained the platform specificities.
I always wanted to also support ObjC (to be able for example to use the Server on iPad), and now there is aworking available Google project which allows to convert non-graphic Java programs to ObjC. I think that it would not be such hard work to convert the generic part from java to ObjC (it's really very abstracted),, and add the specific graphics layer on that.
I think that by doing that I will gain some further knowledge on how to abstract more the core part of the code to be able to do something in the lines that you propose.
What do you think?
Herve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As explained here: http://sourceforge.net/apps/mediawiki/j661/index.php?title=Embedding_the_server, it is possible to embed the Server in a C/C++ OpenGL app. However we use the JOGL library for that, and very recently switched from 1.1.1 (a VERY old version) to 2.0 rc5.
Of course this had the result of breaking this feature, but with the very kind help of the JOGL devs, we were able to make it work again (the last fixes are still not in trunk, but should be shortly).
However, the discussion with the devs have opened a whole new world of possibilities. In short, the OpenGL rendering of the whole Swing /ARINC 661 hierarchy was only performed by creating an OpenGL texture and rendering it in the eternal OpenGL context, which was not very efficient and the graphic quality was not so good.
There is a mature project called GLJ2D which allows to draw (yes, really draw) efficiently in any OpenGL context. Our first tries with this code (which relies on JOGL of course) are VERY encouraging, which will allow people to use J661 embedded efficiently ikn any OpenGL context, for example in FlightGear ;)
Herve
The textured mode is working again, but now with the last autobuild version of JOGL, rather than JOGL 1.1.1.
The "direct" (no texture used, direct OpenGL orders using GLJ2D) mode begins to work in some simple use cases.
Now everything is working well, even in the direct OpenGL mode, The rendering in an external OpenGL context is identical to the pure Java swing rendering. We still need to document this well (this is not really the case for now), and finish to add events hand;ling (it's in fact not very difficult).
Are there any code examples illustrating how to make render a texture into a different GL context such as flightgear or some other software? What is needed to support j661?
thank you
Michael
Arghh sorry for y lack of answer, I did not see this last question because I forgot to monitor this thread. The only requirement is to have a Java 6 or Java 7 JDK installed on the platform (n fact it it not necessary to formally install it, having it put somewhere on the PC or Mac is enough).
You should also have the OpenGL headers because you will need them on the C or C++ part of your code. This wiki article here shows how to perform the embedding: http://sourceforge.net/apps/mediawiki/j661/index.php?title=Embedding_the_server. We support the ability to define more than one context meaning that you also can embed more than one display in your C application.
I will update the "native" part of the binary release to have a complete working example of a C app example for that. It might not work anymore since we updated a lot of things since the time I created the current version. I might also put it in a contrib release rather than in the core release, which will make possible to add more things to flesh out the example itself.
Our implementation work well, the current implementation take approximately 20 ms to render a whole complex display including a working Map. Also it respond t user events like clicks or drags coming from the C code.
Hervé
there is another idea to use code generator: http://sourceforge.net/tracker/?func=detail&aid=3112366&group_id=349118&atid=1459660
You could use the same method to generalize the CDS and transform it into a different target language, which does not require a runtime environment (unlike Java or C#) -for example C++, ObjC, C or even SPARK/Ada.
From an implementation point of view, the transformation could always require a struct/class to provide a certain platform-specific interface (methods), to deal with platform differences (setPixel primitives, mouse handling, networking etc).
That would make it possible to support different backends (OpenGL, DirectX, GDI, X11)
By convention, you could also make this GPL so that people are bound to the terms of the GPL, but your original Java CDS code could then be more easily used on other platforms.
This would also ensure that people would contribute their own language/platform interfaces.
Hello,
Your idea is good, but the only problem is the amount of work it would need to be able to do this.
However, I think one (small) part of this task has already been performed some time ago, on the J661 Java CDS. When I tried to port J661 to Android, I discovered that there were a LOT of differences between Oracle Java and Android's Java. There are so many things in Android which are different (IMO they are worse, but it's just a personal opinion), that I had to abstract a lot of constructs which I took for granted that it ended with (it's the frodo branch) two parts : the generic one, not tied to any graphics or other specificities, and working in both the Oracle JRE and Android, and a (pluggable) other one which contained the platform specificities.
I always wanted to also support ObjC (to be able for example to use the Server on iPad), and now there is aworking available Google project which allows to convert non-graphic Java programs to ObjC. I think that it would not be such hard work to convert the generic part from java to ObjC (it's really very abstracted),, and add the specific graphics layer on that.
I think that by doing that I will gain some further knowledge on how to abstract more the core part of the code to be able to do something in the lines that you propose.
What do you think?
Herve