Thanks for your answer!
As for our experience, we are currently migrating a big UI application (Java
ARINC 661 Server: http://sourceforge.net/projects/j661/) from being
Swing-based to JavaFX based. We still keep the Swing compatibility, but we
found that using the JavaFX scene graph makes things MUCH more simple for us.
And in our very preliminary tests it does seem that our performance is good
(the application is almost completely ported and working, but several of our
custom widgets implementations still have to be implemented in JavaFX, so we
don't have direct comparisons yet).
However, as you talk about the scene graph / the canvas API, I have a question. We are
mostly rendering controls and Shapes (exactly what JavaFX scene graph is about), but we
also have to render Map overlays (with waypoints, flight plans, etc...). We used to do it
by overriding the paintComponent method of a custom Component in our Swing
implementation, dealing directly with the Graphics2D Layer. The "natural" path
for us with JavaFX would be to use the Canvas widget, and GraphicContext, but reading
your answer, I begin to suspect that we could maybe achieve a better performance with a
simpler architecture by using directly the scenegraph for that too. What do you think?
Herve
2013/5/29 Richard Bair <richard.b...@oracle.com>
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/
