Oracle made it clear that Swing will be discontinued in favor of the new JAVAFX toolkit, which does not support OpenGL. Does this not compromise future versions of AOI when the JVM does not support Swing anymore? After all, OpenGL (JOGL) play a significant role in AOI main interface.
Swing isn't going away. They're just recommending people use JavaFX for new projects, and putting most of their effort into it going forward. See http://stackoverflow.com/questions/15362783/is-javafx-complete-replacement-of-swing.
Humm, this article is a bit outdated (2013), I feel more comfortable with this extract from Reddit:
"Java 1.0 APIs are still supported. They've deprecated stuff but almost never (never?) removed it. So no...It's not dead. It's not the current UI toolkit, but it's still very much in use."
OK, the support still there, but my point is: Swing will not evolve anymore and the IT world changes faster and faster; how many years until it is complete obsolete and unusable for new features? The same with AOI then?
That would depend on how one defines "Obsolete."
AOI as currently constituted is rather uncompromisingly a Desktop-Oriented Application, with a keyboard/mouse interface. For persons using such hardware, I doubt that conventions will change much in the forseeable future, so no major upgrades to the UI would be required.
However, tablet/touch based interfaces are here, and a major part of the device market. JavaFX is supposed to have much better touch/gesture support than swing ever did, So it would seem the obvious choice for supporting tablet interfaces, at least for editing (I don't want to think about trying to run the renderer on a tablet or phone) But JOGL integration accross the pipleine seems to be currently impossible.
AOI does use JOGL only for interactive rendering of the scenegraph, not for other UI components. It is possible to embed a Swing node in a JavaFX UI, and (supposedly) use JOGL to render to that node. However, this does not help with any attempt to support tablets, etc. as swing is not available on Android, AFAIK.
"t is possible to embed a Swing node in a JavaFX UI, and (supposedly) use JOGL to render to that node.*
No, it isn´t. The JavaFX interface uses the GPU internally, but instead of using only OpenGL, it uses Microsoft Direct3D on the Windows platform. Because of this, it is not possible to insert an OpenGL content within the interface, mixed with the other controls. Only in a separate window (according to some, I have not tested).
But as Oracle has donated the JavaFX code to the Open JDK community, it may change in the near future due to pressure from game developers, since they (and I too) rejected the JavaFX 3D at all.
I've never looked at JavaFX in any detail, but at least in principle, I can understand why Oracle would want to replace Swing. The whole reason I created Buoy is that I thought Swing was badly designed, and I wanted to create something more sane to work with. Also, with Swing it takes a lot of work to create the sort of UIs that are very popular these days: lots of animation and transparency and components with highly customized appearances. Having a display layer that's customizable with CSS should make all of that a lot easier.
On the other hand, "old fashioned" UIs with standard buttons and menus and such are also still very common. That model isn't about to go away. Just as there are tons of applications with UIs based on Swing, and those aren't about to go away either.
Yes, there are many applications in Swing out there, but would someone start a new application from scratch today in Swing? In addition, there are many new features in JavaFX that would be of interest to AOI. I came to think of a conversion, but I ran into the OpenGL problem.
There is, of course, the software version of CanvasDrawer, but I do not know if it would be viable (in terms of performance) to use it.
would someone start a new application from scratch today in Swing?
would someone start a new application from scratch today in Swing?
If it requires OpenGL, clearly yes. Otherwise, I don't know. I'd have to learn a lot more about JavaFX to say.
Is the option of not using OpenGL in the preferences window working? I disabled it and saw no difference. Perhaps in more complex scenes, I used some of the gallery as a test.
It is working, but not before you restart or at least open a new window. (You knew that, I know. ;) )
One thing where OGL certainly make a difference is, when you use reference images in the scene. It of course depends on your HW and the size of the image(s) you are using but there will be a point, where OGL is much faster and smoother. -- Even so that working without OGL becomes virtually impossible.
One thing I just noticed is, that there is a difference in how SWDrawer and GLDrawer handle transparency of reference images. (On AoI 3.0.3 that is).
With just curves and simpe objects on the scene you may build quite a lot and both of them are still powerful enough unless your gear is ~10 years + of age.
My unprofessional observations. :)
I've been seeing some rendering glitches in the software renderer view, but have not taken the time to try to track them down, as the OpenGL rendering is now much more stable after upgrading our JOGL library. (Appear to be z-depth errors)
Yes, I saw the warning and restarted the program before load the scene, ;-)
I saw the glitches too, but don't back to openGL to compare.
I found the result very promissor. JavaFX has an object called Canvas which has a GraphicContext object much like Graphics2D, so it´s possible (with care) to convert SWDrawer to it. And, since JavaFX is internally renderized by GPU, it will use OpenGL (or Direct3D) anyway. OK, not so good as JOGL, but not so bad at all. I'll try to do something about it.
If you really want to try a conversion to JavaFX, converting the SW renderer to use GraphicsContext is the least of your worries, and not the way to do it anyway. - In that case, you would only be getting GPU acceleration for the GUI 2d stuff, as the SW renderer would still be running on the CPU.
You would be better mapping AOI objects to the JavaFX 3d scenegraph. This Tutorial is a decent introduction.
There are some limits there, though, including limits in the lighting setup, and you would also have to map AOI textures to JavaFX materials.
The bigger issue is that you would also have to re-build all of AOI's GUI in javafx. This includes custom controls and dialogs that are built in bouy. (Swing API Wrapper) This would also break compatibility with many existing plugins, and any scripts that attempt to display an interactive interface. It's further complicated by the fact that many of the GUI bits are embedded with the editing logic that they represent.
One would almost need a two-pass refactor: One to decouple the editing logic more thoroughly from the GUI, and then another to replace the GUI framework. Overall, a very big project, and the reason that we seem unwilling to put work into it, unless there is a very clear reason.
the reason that we seem unwilling to put work into it, unless there is a very clear reason.
I agree. The reason I think about this conversion is not a need to update the program, but to add some features that would be useful to me and JavaFX would make it easier.
A pure and simple conversion is out of my plans, what I want is almost like a new program taking advantage of the AOI features with a new GUI, with no compatibility with the current version.
I've been thinking about it for a few months, but I stopped because of OpenGL.
You would be better mapping AOI objects to the JavaFX 3d scenegraph
JavaFX 3D is impractical for serious modeling programs, and I'm hopeful that one day, Oracle will wake up and release a GLNode or something, which would replace the software version in the architecture I figured out.
One would almost need a two-pass refactor: One to decouple the editing logic more thoroughly from the GUI, and then another to replace the GUI framework.
That is precisely my approach; Also, I plan to keep the GUI and 3D engine separate.
Anyway, I'd rather do it myself, mainly because there's a lot of things missing, and if someone asked me for any project documentation today, I would have nothing to give; Most things are still in my head.
My intention to start with ViewerCanvas is because it is the heart of the GUI and almost everything deal with it.
Any day, who knows, I have some results to show.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.