JavaFX graphics performance and suitability for advanced animations

[Herve Girod]

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.bair at 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/