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 "smoothness"). 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 either. 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 JavaFX? 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 curve. 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... Felix On 22 July 2016 at 08:51, Hervé Girod <herve.gi...@gmail.com> 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.bembr...@gmail.com> > 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.gi...@gmail.com> 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.bembr...@gmail.com> > 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.to...@oracle.com> > 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.rushfo...@oracle.com> 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.rushfo...@oracle.com> wrote: > >>>>>>>> > >>>>>>>> Yep. >
