Hi John, > 1. Can someone from Oracle please outline the full range of > applications for which JavaFX is or will be suitable for?
That's a pretty broad question. Lots of stuff? At a minimum everything Swing and SWT were used for, as well as mobile and embedded UIs, rich media, graphics, etc. I don't expect somebody to write Halo 5 with it. > 2. Is there something inherent in the JavaFX architecture (such as > CPU/GPU interaction, the performance of the JVM or the Java language itself) > that limits its suitability and thus effectiveness in advanced > animations/visualisations? Absolutely not, in fact, quite the opposite. The basic architecture (threading model, GPU usage model, etc) is designed for high concurrency and throughput. Some of the features in Controls though (like CSS lookup, color derivation, etc) put a tax on performance. When it wasn't exposed in the API, every design decision is made with performance as a for most thought. When it comes to API usability is considered primarily but performance is also always considered (along with security). And for every feature that adds weight, there is a way to avoid it when absolutely necessary. > 3. Is this choppiness and lack of smoothness I have experienced > typical of JavaFX performance or is it some issue with my > environment/drivers etc.? Hard to say. I saw a couple weeks ago a machine where scrolling the table view was 14fps whereas it was 320fps for me. The difference was the other system was falling back to the software pipeline. To determine what you're seeing, we need to know whether what you're running is producing consistently slow results or erratic results. Also, we need to know whether you are render bound or compute bound. What's taking so long to complete? We have seen situations where we are preparing a frame but never rendering it, which might also be contributing to the choppiness. > 4. Is JavaFX more targeted at form-based UIs rather than high > performance graphics? No. > 5. Do you have any other comments on JavaFX and its suitability for > advanced animations and visualizations? The biggest issue at present architecturally is that we don't expose any way for you to *really* draw without the scene graph. The Canvas gets you partway there, but ultimately that guy is still just buffering up drawing commands and issuing them later against a texture, rather than allowing you to go directly down to OpenGL. So that's a feature that is missing that is going to impact some people. Instead, you have to do everything with the scene graph which in more advanced scenarios means a huge scene graph and tons of memory. We're still making a lot of progress on the raw performance side. We had an embedded hack-fest a couple weeks ago in which performance on desktop went from 320-800+fps on table view scrolling, which in large measure came down to reducing the number of state switches on the graphics card (and the resulting decrease in the number of OpenGL calls). However choppiness is often the culprit in perceived performance rather than actual fps. One thing you can try is to run your application with -Djavafx.pulseLogger=true and analyze the output. This records the amount of time spent in various phases of the pulse, the number of dirty nodes processed per frame, etc. One thing I saw a couple weeks back, for instance, was that if more than 15 nodes are dirty (or is it 12?) then we punt on determining the dirty region and accumulate the entire parent. This is a heuristic used to trade off figuring out how big the dirty area is against just drawing it -- sometimes it is cheaper to do the former, sometimes the latter. Also each individual dirty region probably comes with some overhead in terms of setup for each render pass (each unique dirty area ends up getting its own render pass), and this fixed cost has not been analyzed and perhaps needs to be factored in to our determination of the number of dirty regions we support, or the heuristic in any case. Are your slow examples reproducible? If so we need the test case. Is there an issue filed? We can't fix things we can't reproduce. We spend a *considerable* amount of time and energy on performance and for the things we're measuring we're doing well. As the saying goes "what's measured, improves". After the switch to gradle and the new project layout, one thing I'm going to look at is using JMH[2] in OpenJFX so we can write micro benchmarks and have them easy for everybody to run and contribute to. Our current set of micro benchmarks are based on the predecessor of JMH which was the JRockit benchmark suite and was proprietary (hence we cannot just open source our existing benchmarks without doing some rewrite). [1] Attributed to Peter Drucker http://blog.johnrchildress.com/2012/06/05/key-business-metrics-and-milestones/ [2] http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/main/java/org/openjdk/jmh/samples/
