Skip to main content

Interested in JavaFX? The JIRA is your friend

Posted by opinali on June 18, 2011 at 5:16 AM PDT

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.

Critical Bugs

Major Bugs

  • 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.

Medium Bugs

  • 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.

Comments

<p>Osvaldo,</p> <p>Multi platform and anti-aliasing (or ...

Osvaldo,

Multi platform and anti-aliasing (or not) is not about technology, as one might think, it's about bad communication and that's what these people need to learn or be taught.

If you post a beta for a product that you know will be multi platform, but it's only released for Windows, you need to write EVERYWHERE that the other plasforms are coming and be clear that you commit to it. Same thing with anti-aliasing (and the sub pixel type), if you post a screen shot with ugly jagged rectangles you need to be very very clear that this will be fixed before final release.

You see only a very small part of the readers will bother to look up the facts as you have done. Many will just say "that doesn't look good" and move on. You won't even know they've been there since they don't come back and don't reply.

Sun had this problem where the developers wrote a lot of blogs without fully understanding the importance of communication and how receivers react in combination with the simple fact that the reader doesn't know as much about it the write do. Sadly this seems to have been transferred to Oracle.

<blockquote>&quot;JavaFX's controls can suffer high ...

"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."
Ouch!

It's not clear to me how important these subsystems are for ...

It's not clear to me how important these subsystems are for "real world" performance... but sluggish layout can make FX look bad in a benchmark that animates the shape of containers, forcing full reflow of all childrens' layout at every frame. The worst real-world scenario I can think of, is window resizing: grab the window's resize handle and drags it, and the window repaint is choppy as you drag. I can observe this with a simple demo app that shows a single TableView, but this control is internally very complex, it should be using many child nodes with dynamic layout. Anyway it's a problem for user-perceived performance, but it seems the layout and CSS subsystems are relatively immature so they should have plenty low-hanging perf fixes to do.

<p>&quot;One of multiple bugs telling us that the Linux port ...

"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."

This sounds pretty much what happened to AIR. Next big telling sign is that the source is still missing, so IcedTea/RedHat can't fix it.

Does the implementation of GStreamer in JavaFX restrict what codecs will be available? Will it be possible to just use the system libraries for WebKit and GStreamer when shipping on Linux?

I certainly don't want to depend on Oracle to provide security fixes for WebKit, they can't even get the native Java ones out in time.

<p>[quote=smcj]</p> <p>This sounds pretty much what ...

smcj wrote:

This sounds pretty much what happened to AIR. Next big telling sign is that the source is still missing, so IcedTea/RedHat can't fix it.

Definitely not the same thing; there's no back-pedaling, it's just that the non-Windows ports are second priority just like it has been since JavaFX 1.0, and in fact since JDK 1.0. ;-)

smcj wrote:

Does the implementation of GStreamer in JavaFX restrict what codecs will be available? Will it be possible to just use the system libraries for WebKit and GStreamer when shipping on Linux?

I think the FX media stack integrates with native codecs, but not sure, it's not my turf and I don't know much about GStreamer either.

smcj wrote:

I certainly don't want to depend on Oracle to provide security fixes for WebKit, they can't even get the native Java ones out in time.

The JavaFX runtime includes its own, private WebKit library, and also GStreamer, at least for the Windows port where theres libraries are not available in the OS. WebKit should certainly be private even in a platform like OSX, for pretty much the same reason that Google Chrome for OSX has its own, custom build of WebKit instead of relying on Safari's. But for GStreamer I'm not sure, maybe JavaFX's port for Linux may just use the standard gstreamer libs from the OS, but your guess is as good as mine.

In any event, it's a good point - JavaFX's runtime contains a lot of native code, so FX's attach surface is relatively high. Any security bug in GStreamer or WebKit may become a security bug of JavaFX. I guess the Java plugin will buy you some isolation, browser with strong plugin and tabs isolation will buy even more, and maybe the FX runtime will be careful in the JavaFX bindings to these native runtimes to make exploits difficult. But there's no public info about this now...

<p>&nbsp;Hi Osvaldi,</p> <p>I just run a quick bugs stats ...

Hi Osvaldi,

I just run a quick bugs stats report at JIRAGrader for Runtime project. You might be interested to check this out at http://jiragrader.com/runtime.

Mark