Scene graph performance

Felix Bembrick felix.bembrick at
Fri Jul 22 00:35:24 UTC 2016

I am willing to accept that perhaps FXMark is written so poorly that it
does not permit JavaFX to perform as well as it could (possibly
significantly so) on any particular platform.

And I am indeed going through the code line-by-line and doing all manner of
profiling to try to answer this question.

But ultimately, the actual scene graph animations are *very* simple in
structure. They simply comprise a number of nodes with parallel transitions
built up from those selected in the list and the effects selected are
applied to each node.

It's basically just using transitions and effects exactly as documented and
in the simplest way possible.

Now, perhaps there are "other" less obvious ways of constructing parallel
transitions and applying effects or special tweaks that I am not aware of.
Perhaps there are ways of optimising the performance in a number of ways
that I am not aware of.

But, I have researched these issues on StackOverflow etc. (in fact the
whole interwebs) and I have yet to find anything which I am obviously doing
very wrongly or anything which can even marginally improve the performance
(and by performance I refer to FPS and a visual interpretation of

Now the latter of those metrics is clearly not at all scientific, but FPS
is very scientific. But, maybe it's a case that JavaFX *could* render at a
faster frame rate but simply *doesn't need to* (as 60 FPS is really ample
for most scenarios).

However, when you apply certain transitions (especially rotation for
example) and certain effects (especially Glow or Bloom), the entire
animation of even just 25 nodes can literally "grind to a halt".

Does that matter? Well, I guess it matters to some and not to others.  Like
most things.

I guess my overriding concern is that it's not so much that the frame rate
shows little "improvement" on my beast of a machine, but also that those
especially slow transitions and effects show little or no improvement

So, if for example, you wanted to build a game with JavaFX, you cannot use
the scene graph and utilise nodes for every "entity" in the game and expect
to get high performance "action".  Your only realistic option is to write a
2D (or pseudo-3D) game using Canvas because the Canvas node performance is
quite good.

Which of course could raise the question, why even *have* a scene graph in

When JavaFX was first "conceived", a different approach could have been to
simply add the key missing components to Swing such as media and a decent
browser control and improve the GPU utlisation of what was already an
immediate mode (and hardware accelerated) toolkit (ala Canvas) and you
would have much more quickly had effectively what we have right now: a
toolkit primarily aimed at building business/forms applications (not games
or advanced visualisations) with a few "fancy/sexy" bits thrown in, BUT you
would also have a vastly larger collection of highly customisable controls
that have stood the test of time and there would also be almost no learning

So, yes it's a different topic and a different thread and it may not be one
that people want to discuss, but I would like to pose the question at some
point: "What advantages does the scene graph give JavaFX over the immediate
mode rendering of Swing?".  Well, I guess one obvious thing is a
declarative representation such a FXML but, then again, there have been a
number of GUI builders for Swing for many years that basically do something
very similar (only it's "optional").

At the moment, it's almost as though the scene graph is more of a hindrance
(at least in terms of rendering performance) than a benefit.

I personally would love to see the JavaFX scene graph be able to work just
as OpenSceneGraph or the way scene graphs of advanced game engines work
with greatly improved performance over what we have now.

That however seems to be at least 4 years away from ever happening...


On 22 July 2016 at 08:51, Hervé Girod <herve.girod at> wrote:

> We use a lot of Nodes which we update dynamically from another Client App.
> We also use JavaFX animations, but admittedly not a lot of them
> concurrently.
> In our case JavaFX animations are mainly linked to user interactions, a
> lot of what is dynamic in our apps is directly a result of real data
> changing in real time (such as track positions or plane attitude for
> example).
> But these changes can update a lot of Nodes concurrently, and not always
> simply by translating a parent container. For example if you have a digital
> Map with a lot of real world content (flight plan, waypoints, tracks,
> etc...), and the reference of the Map is the aircraft, you can't just move
> the whole map when the position of the aircraft changes, because you have
> to compute the coordinates of each element in the projection system.
> Hervé
> Sent from my iPhone
> > On Jul 21, 2016, at 23:55, Felix Bembrick <felix.bembrick at>
> wrote:
> >
> > Are you using nodes, transitions, effects and animations? Or are you
> using the Canvas node only?
> >
> >> On 22 Jul 2016, at 07:33, Hervé Girod <herve.girod at> wrote:
> >>
> >> I really don't understand all this. We use Java FX 8 in a graphic
> framework where we need high performance (prototyping Cockpit Display
> Systems with dynamic Maps and Head Up Displays), and we find that JavaFX
> performance is pretty good our use case. For example, Qt / QML performance
> is far worse in our POV, for no real additional simplicity of usage for big
> projects. We also used OpenGL before (used JOGL), but (at least for our own
> usage) what additional performance benefits we could maybe achieve were not
> worth the amount of work we would have needed to get them (if we had any).
> >>
> >> Hervé
> >>
> >> Sent from my iPad
> >>
> >>> On 21 juil. 2016, at 23:09, Felix Bembrick <felix.bembrick at>
> wrote:
> >>>
> >>> Yes, well I think this the problem:
> >>>
> >>> 1) Going on history, it would be a best case scenario for Java 10 to
> be released in 2020 (but more likely 2021).
> >>>
> >>> 2) With JavaFX, we are already "behind the game" (pun intended).
> >>>
> >>> 3) JavaFX itself has evolved much slower than its competitors.
> >>>
> >>> 4) Technology in general will have moved ahead by massive leaps by
> 2021 (including our competitors).
> >>>
> >>> 5) If the *first* optimised JavaFX scene graph is not released until
> 2021, I genuinely fear that not only would "the ship have sailed" but, it
> would actually be way over the horizon and completely out of sight.
> >>>
> >>> Felix
> >>>
> >>>> On 22 Jul 2016, at 06:51, dalibor topic <dalibor.topic at>
> wrote:
> >>>>
> >>>> There is no JDK 10 Project in OpenJDK yet, so there has been no
> proposed schedule for it yet.
> >>>>
> >>>> cheers,
> >>>> dalibor topic
> >>>>
> >>>>> On 21.07.2016 20:51, Felix Bembrick wrote:
> >>>>> What is a "ball park" figure (i.e. around the 6-9 month granularity
> if possible) for the the release date for JDK 10?
> >>>>>
> >>>>>> On 22 Jul 2016, at 04:42, Kevin Rushforth <
> kevin.rushforth at> wrote:
> >>>>>>
> >>>>>> Oh, I was agreeing with the analysis of what *would* need to be
> done. I am not saying that I think it *should* be done, given resources
> other priorities, etc. Having said that, as I mentioned in an earlier post
> a month or so ago, we will be collecting ideas for possible JDK 10 features
> once JDK 9 is finished. Perhaps this could go into the bucket of things to
> consider, but it isn't something I would think would be high on the
> list....compared to, say, WebGL, some sort of interop with native
> rendering, updated graphics pipelines (we're current stuck on DX 9 and GL
> 2), public API for UI Controls Behaviors, etc.
> >>>>>>
> >>>>>> -- Kevin
> >>>>>>
> >>>>>>
> >>>>>> Felix Bembrick wrote:
> >>>>>>> Well, I'm putting my hand up for this.
> >>>>>>>
> >>>>>>> Kevin, would you like to discuss this with me on or offline?
> >>>>>>>
> >>>>>>> Felix
> >>>>>>>
> >>>>>>> P.S. Thanks Markus for your insight!
> >>>>>>>
> >>>>>>>
> >>>>>>>> On 22 Jul 2016, at 04:22, Kevin Rushforth <
> kevin.rushforth at> wrote:
> >>>>>>>>
> >>>>>>>> Yep.

More information about the openjfx-dev mailing list