Yes, that’s what I meant. And I’m hoping I can layer a portal system on top of JavaFx2.1, so as to be able to have decent sized world models without overloading the scene graph.
Hi!
JavaFX 1.3 on Linux & Mac uses JOGL, I can prove it easily as I have found JOGL jars in the SDK and if I remove them, it does not work anymore ;D
I have a lot of source code in free open source projects and in commercial projects that uses JOGL with Ardor3D and 2 scenegraphs of mine, I’m not the only one who has a lot of legacy code using Java bindings of OpenGL (JOGL, LWJGL) and various scenegraphs. There are some OpenGL GUI libraries for Java but they are some noticeable drawbacks, Nifty GUI uses too much memory for example.
In my humble opinion, JavaFX 2.0 should at least provide a way of forcing the use of the OpenGL renderer to avoid conflicts between Direct3D and OpenGL at driver level (which means it should respect the flags about Direct3D/DirectDraw including “noddraw” and those concerning OpenGL). Moreover, it would be fine that Oracle developers working on JavaFX and Prism could work a bit together with the maintainers/contributers of Java bindings of OpenGL (both JOGL and LWJGL) to implement some interoperability. Using JavaFX 2.0 in my own projects would allow me to save a lot of time especially in commercial projects. Please let me know what could be done about these aspects.
@Joe: Thanks for the answers. You’ve certainly built up my expectations.
Wait, what? Is there a JavaFX API for PhysX???
I found a post from September which suggested that there might be a degree of JavaFx/Swing interoperability by making JavaFx a heavyweight component in swing. However this doesn’t seem to have been mentioned since, so maybe it was too hard. However if true, I wonder if it would be possible to have a JOGL heavyweight component and a JavaFx heavyweight component at the same time. It might not be, if they are both using the same interface. Also what happens if two heavyweight components overlap and one has transparancy?
Anyway, I signed up to receive email updates on the Beta programme.
In JavaFX 1.2, it was even possible to mix AWT with JavaFX, allowing to use GLCanvas and JavaFX nicely. In JavaFX 1.3, it was no more working and the remaining Swing interoperabily was not working with JOGL, only pure Swing things were drawn.
The road map has been updated(http://javafx.com/roadmap/):
[quote]JavaFX 2.0 APIs can be used within a Swing application to provide a smoother transition to JavaFX. JavaFX components, such as WebView, will allow developers to extend existing Swing applications and gain experience with the new JavaFX APIs.
[/quote]
Also explains what is Prism:
[quote]All new fully hardware accelerated pipeline, project name “Prism”. It will target DirectX on Windows platforms (both 32 and 64 bit) and OpenGL on other systems. It will also support software rendering when the graphics hardware on a system is not sufficient to support hardware accelerated rendering. It will also use an all-new windowing implementation instead of AWT for interfacing with the operating system.
[/quote]
I would rather see Swing entirely replaced with JavaFX then mix the two. Especially if JavaFX will be all hardware accelerated. Swing and Java2D were good for the time; but these days they look dated and there is a kind of typical look to them (you can usually always tell something is an applet when you look at it).
Swing is rather good at what it does though. It’s still the best crossplatform widget toolkit out there, handily thrashing Qt and GTK in terms of look, feel, and ease of use (heh, mainly by being in Java in the first place).
Cas 
All this touches on 3 questions I’d like to ask, though I’m not necessarily expecting answers on all of them …
-
Does Prism have something akin to the JSL shading language in Scenegraph Effects, and if so, is it something there might be an API to access? WORA shaders sound good!
-
Is there a plan for some sort of bridge between Prism and AWT / Swing / Java2D (mainly thinking of Swing rendering through Prism)? I realise this is likely to be suboptimal - just thinking of the possibilities of incrementally updating larger projects - probably more of a general apps than games question.
-
When will there be (or is there and I’ve missed it) any clarification of what license all this will be released under? I’m hoping that it will all be licensed under the same license as OpenJDK - a two tier Java ecosystem doesn’t seem to benefit anyone. Two things to my mind that will help drive adoption are to undercut the competition (and Flash is already free!) and to provide some sense that the platform has a future and things won’t be discontinued at the drop of a hat (which, quite frankly seems to be most peoples’ impressions of JavaFX so far!)
Best wishes, Neil
PS. For those who liked JavaFX script but aren’t aware, it is still being developed as Visage (http://code.google.com/p/visage/) with an Android binding in the works.
The problem is that Swing forces a threading model - you can only create, modify, and paint Swing components on the Event Dispatch Thread. This fundamental inflexibility is very frustrating and stops us from using it in games. It also makes code look butt-ugly since all swing code has to be run in an anonymous Runnable class and then have ‘invokeLater’ called on it.
Other problems:
No browser component
Sub-par text components. I wish they incorporated more of Netbean’s improvements back into Swing.
Many components are not extensible since there are lots of private and package-level fields which can’t be seen by sub-classes.
AFAIK, thats pretty normal for UI toolkits.
Interesting, I didn’t know that.
What about the OpenGL GUI’s like FengUI and TWL ( http://twl.l33tlabs.org/ )? I thought that they make do without scheduling stuff on their own thread, because all openGL painting has to be done on the same thread (at least in LWJGL, I don’t know about JOGL).
dunno about TWL, but I doubt its components are threadsafe.
Swing, QT, Windows forms, GTK, Cocoa are all generally non-threadsafe, at least parts related to UI.
My main issues with Swing are…
- the API is outdated such as making much better use of enums over int constants and generics
- good flowing layouts are difficult to build because they can only really be learnt through experience (and for me it always requires tonnes of JPanels and LayoutManagers)
- Swing is not that easy to theme (especially if you want it to look good or fit a site-theme like you can with Flash, Silverlight or HTML inputs + CSS)
- Swings cross-platform themes don’t look that great (although this is mainly because everything else looks so much better)
Again, it’s great for the time it’s just that given that Java is the most popular language in the world I think it deserves something much better. Especially if you want to build an applet. Something on par with WPF would just be awesome!
Substance looks great though
Ah! Accidental post. I meant to click modify but clicked quote instead!
[quote]Substance looks great though
[/quote]
Yeah it is great. Its a shame that it has no more updates, quite annoying when I still find a number of bugs. I really hope someone else will pick up and continue its greatness.
My frustration is that Swing has been made inflexible so that it is thread-safe. To dictate that all UI code must run on a designated single thread seems silly. All that is really needed is a guarantee that UI code is run from one thread at a time. The actual thread it is run from shouldn’t matter.
I wish there was a UI toolkit that had a single update(ArrayList events) method. Of course the method should only be called by one thread at a time, maybe it should be made synchronized. This method would process the list of events and run all updates. That way the UI toolkit could run on top of LWJGL or AWT or whatever without being tied to an event or threading model. The UI toolkit could be used with LWJGL where events are polled from any thread, or AWT where events are listened for on the event dispatch thread.
I do like the way all Swing painting is all done through the Graphics2D object. The GoldenT Game Engine devs even extended Graphics2D to draw using LWJGL. Pretty cool.