Interested in JavaFX? The JIRA is your friend
JavaFX 2.0 is not multiplatform! It can't do subpixel antialiasing!! … these were among the reactions to the first beta releases, that I'm not sure to understand as trolling or simple laziness. These mysteries are usually solved with a simple look at JavaFX's public JIRA issue tracking system. The current implementation is still a beta, not even a feature-complete beta, so there are many bugs that will be fixed and functionality that will be added or completed before the FCS.
Here's a quick review of a few interesting open bugs (or very recently closed) at this time. This is just a snapshot at a specific date and time, but it's a good exercise to get a feeling about the project progress.
- RT-13660: QuantumToolkit can schedule the pulse better to improve performance - Some applications may have their performance limited by a bug in event dispatching. People running benchmarks, like this blogger here, must be aware of this kind of bug.
- RT-13612: Mac OS: Invalid Memory Access when quitting a JavaFX application - One of the many evidences that JavaFX will support other platforms. This bug was just closed a few days ago, so it's also possibly one of the reasons why the OSX port was not yet promoted to public beta.
- RT-10770: Support LCD subpixel text - Yes we will have subpixel antialiasing. JavaFX can use both the platform's native text rasterizer, or its own portable rasterizer, depending on some heuristics summarized in this issue.
- RT-9449: Need to support Windows 64-bit as a platform using 64-bit JRE - The first beta refresh, b30, introduced the Win64 port. This bug (just recently resolved too) illustrates the effort required even for a "simple" porting like Win32 to Win64.
- RT-5474: Scene graph optimizations - One of the multiple optimization bugs in the Critical category, this is actually an umbrella bug that groups 10 individual optimizations. Performance is an ongoing effort, even though the current runtime is already faster than JavaFX 1.x. If something looks slow for you, check the JIRA to see if it's a known issue.
- RT-14045: TableView perf when scrolling up and down - A more "down-to-Earth" performance bug; JavaFX's controls can suffer high overheads from the layout and CSS subsystems. JavaFX flies on benchmarks like my JavaFX Balls, that heavily exercise graphics and animation but make zero use of layout or CSS; these things got to be optimized so conventional UIs will also have great all-round performance.
- RT-14038: Need public API for rendering to an image and converting to BufferedImage - this is basically what I have requested here and filed here; but it's important also to enable printing support, right now an important feature gap (although you can do it with internal APIs).
- RT-13007: Need to add any() and discard functionality to JSL language - This apparently esoteric, recently-fixed issue is related to Decora, the internal library used by JavaFX to code GPU shaders in a portable manner (Java Shading Language, which is converted to HLSL for DirectX pipeline, GLSL for the OpenGL pipeline, or Intel SSE if your OS/GPU won't support any of the former).
- RT-11283: Media rendering path needs to be revised for JavaFX 2.0 - JavaFX 2.0's brand-new and much improved media stack is GStreamer, but the integration between that code and the rest of JavaFX is still a work in progress. This bug documents some apparently low-hanging optimization fruits. It also tells you that the WebView shares the same media components what it plays HTML5 <video> and <audio>, which makes a lot of sense; apparently the web component is well-integrated into the JavaFX architecture, it's not just a cheap embedding of upstream WebKit into the toolkit.
- RT-9466: Support Prism / Glass on Linux - One of multiple bugs telling us that the Linux port exists and will be eventually available… but not in time for 2.0-FCS; very likely only in the next minor update. I guess a beta-quality build for Linux will be released by the time 2.0 ships, but there's no official position and no JIRA clues about this at this time.
- RT-5205: Scenegraph performance: Binary nodes - Describes an optimization that could potentially result in orders-of-magnitude scalability improvement for the scene graph.
- RT-5258: Optimize 3D picking - One of the many bugs covering the big-ticket feature of (initial) 3D support in JavaFX 2.0. The same pipeline supports both 2D and 3D elements, which creates some interesting challenges.
- RT-12100: Swing components inside JavaFX - Notice the "medium" priority; and also the evaluation "We do not currently plan…". The reverse support (embedding JavaFX components inside Swing) is apparently the only kind of integration that will be supported, with JFXPanel. (See Side Note.)
- RT-11191: Consider supporting ES1 pipeline in Prism - Prism already supports OpenGL ES2 as back-end pipeline; that's important for high-end mobile platforms, and also used in the OSX port (the reporter apparently works on OpenGL/OSX porting of JavaFX). OpenGL ES1 support would be good for lower-end devices.
- RT-9983: Circles are rendered incorrectly - I thought I knew all about rendering circles when I studied Mike Abrash's DDJ series long ago… but the recurrence of such bugs in circle/ellipse drawing, from the early days of Java2D and into JavaFX's Prism, tells me this stuff is not that simple.
- RT-7644: Prism: Math.floor and Math.ceil take up a lot of cpu time - Another déjà vu bug. This old Java performance pitfall persists even in current JDKs, where all "simple" Math methods - floor(), ceil(), abs(), min(), max(), signum() - are pure-Java, without JNI overheads. But their implementations are still complex, due to corner cases like signed zeroes, NaNs and infinites, so the methods are bloated enough to prevent inlining and further JIT optimization. High-performance code that handles well-behaved floating-point numbers, such as graphics coordinates, must avoid these "simple" java.lang.Math APIs like the plague. Just write your own one-liner replacements.
Side Note: Swing Integration
JavaFX 2.0 supports embedding of JavaFX components into Swing applications. This allows the Swing faithful, or legacy Swing apps, to benefit from lots of JavaFX power, even though the integration is a bit coarse-grained and one-way. Full integration will never be possible; in the past (JavaFX 1.x blogs) I offered the rendering architecture as the main reason for that, but it's now clear that threading and event processing are also radically different, and there's only so much integration you can make through adapter layers without opening a whole new can of worms. So I was pleasantly surprised to know that JFXPanel is lightweight, which enables seamless visual integration and avoids the small number of lightweight / heavyweight issues that still persist. It's even more exciting as JavaFX can do that with the GPU-accelerated pipelines, no need to fall back to Java2D. I guess JavaFX just renders its scene and then draws the resulting pixel buffer into Swing's Java2D surface… but that's probably easier said than done, and the extra buffer copy is certainly more than offset by JavaFX's fully-accelerated rendering.
Another idea: why should Swing apps pay any tax to use components like the web engine and the media support? These are mostly implemented by WebKit and GStreamer, both native and neutral to the JavaFX runtime. JavaFX does us the big favor of making a Java-friendly distribution of these components (e.g. with JNI interfaces), and bundling them in a runtime that will soon be widely distributed. (And differently to third-party libraries containing native code, e.g. JOGL, it won't require full permissions to run from the web…) You still need a high-level Java layer to make those features available to Java applications, and while the public javafx.scene.media and javafx.scene.web are JavaFX-centric, these are pretty small, and even the larger packages they rely on don't seem to be mostly FX-specific. For example, the lion's share of com.sun.webpane (as I estimated from class names and counts - no sources available) deals with neutral issues like DOM, networking, cookies and authentication. The integration of both rendering and even handling should be a very small piece of this Java layer, and one that would be easy to replace with Swing-specific support. This could allow a Swing program to have a "web view" implemented as a pure JComponent, without any further intermediation of other parts of JavaFX, resulting in less overhead and limitations. The same logic probably applies to the media stack too.
These are interesting opportunities for the future evolution of the combined platforms; even if the strategy is 100% JavaFX moving forward, Oracle could win back a lot of good will from the Swing community by putting the (apparently small) effort of making first-class web and media support available "natively" to Swing, without caveats or limitations caused by an "alien" toolkit in the middle. That support could even become official JavaSE APIs in JDK 8+, and the migration of all shared code to the JRE would make JavaFX's runtime look much smaller (although this may be irrelevant if both runtimes are bundled together, not to mention JDK 8's Jigsaw). If Oracle has no intention to follow that route or if the additional effort is bigger than I estimate, I bet some Swing enthusiasts would do the work, if JavaFX's internal web and media libraries, or at least the native bindings, are documented. Open sourcing these libraries and bindings would be even better, but not really critical.