JavaFX graphics performance and suitability for advanced animations

[Scott Palmer]

I've converted a large Swing based app to JavaFX... but unfortunately not
without issues.

I also much prefer the JavaFX APIs + scene graph.  But I am forced when
testing with JavaFX 8 to use the software pipeline, and with JavaFX 2.2.x
(the only option we can ship with this year) I must used the Java 2D
pipeline.  This is due to major rendering glitches that make our
application entirely unusable with the accelerated pipeline (see RT-30591).
 It's too bad that it took a full port to JavaFX before I discovered this,
as I doubt I will see a fix until JavaFX 8 and I must ship before that's
available.  7u40 is probably too far along for a fix to make it there,
though the vibe I get is that not much is considered for the JavaFX 2.2.x
branch these days anyway.  (Has that changed since the delay of Java 8?)

I hold out hope, but JavaFX still has a lot of issues.  I've filed multiple
bugs about inconsistent layouts, glitchy rendering, etc.  I wish fluff like
3D and a new look and feel could have been put off and more time spent
getting what we have with JavaFX 2.2 cleaned up.  As this thread says "I
don't expect somebody to write Halo 5 with it.", so what was the point of
the 3D stuff? Even "...allowing you to go directly down to OpenGL." makes a
lot more sense for people that need 3D, yet still...  How many desktops
apps need that vs a working combobox or menus (RT-28903, RT-30280)?
Rendering performance, while quite poor in some specific cases (e.g.
transformed Group with Paths in a ScrollPane is 100 times slower than
without a transform RT-25166), is still the least of my worries at this
point.  JavaFX doesn't behave correctly yet... keep performance in mind,
but focus on it when you get things working.

Sorry for the semi-rant, I'm still bummed by my Swing -> JavaFX port being
screwed over by RT-30591.  I thought most of my troubles would be behind me
when I scrapped the JFXPanel for a full JavaFX app.  It looks much better
when it is working -- but most of time time it isn't :-(  It is actually
much worse since with the JFXPanel at least the rendering glitches wouldn't
crap over my entire UI...  I need a drink...  ;-)

Regards,

Scott



On Tue, May 28, 2013 at 8:40 PM, Herve Girod <herve.girod at gmail.com> wrote:

> 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/
>