Re: Scene graph performance

[Johan Vos]

Hi,

I agree with most that has been said here, but I want to add a few things.

I've seen a number of "performance issues" with JavaFX in customer
projects. Most of them are simply due to the application doing things on
the FX App Thread that shouldn't be done there.

Apart from these obvious things, it is indeed mainly the CSS and layout
processing that consumes most of the time. I spent lots of time working on
mobile performance, and in that context the CPU limitation is even more
pronounced, as the GPU on modern mobile devices is pretty good. I don't
have enough different devices, but to give an idea about numbers: when
running a typical app, the GPU load on my desktop is about the same as the
GPU load on my Nexus 5, but the CPU load on the Nexus is 5-10 times higher
than on desktop. I measure this by comparing numbers in the pulseLogger.
Hence, on mobile the limitation that only a single thread can do the
CSS/layout phase AND the rasterisation is really a bottleneck.

However, there are many tricks that can make it better. Contrary to e.g.
Android and iOS, the JavaFX API's still allow for lots of flexibility that
can be very helpful, but that also can easily kill performance. Caching is
one of those things. If you cache the right Node, you'll gain a lot. But if
you cache a Node that often becomes dirty, you screw performance.
There is no general solution for this, I believe. The way to address this
is to create components that work for specific usecases (e.g. cache the
content of a pane while animating, and don't cache it once it might change
again). This is what we do in the Gluon Mobile components.
Complex CSS and layout changes are CPU hungry as well. About the latter: be
careful about bounds that vary (e.g. start with a negative offset) without
any visual consequence, as this will increase the dirty region.

Profiling is the most important thing to do when your application is slow.
Find the bottleneck, fix it, go to the next bottleneck. Each application
has its own bottlenecks, but with enough time, I really believe all
applications can at least be improved.

One of the great things about JavaFX is the decoupling between the API and
the rendering pipeline. If someone writes a renderer that works completely
different from the existing ones, that is fine. All applications should be
able to run with this.

One of the things I'm thinking about is to see if/how Vulkan would be a
good alternative to OpenGL. But that would not speed up the single-threaded
bottleneck, so I applaud all initiatives in that area (e.g. do some
parallel CSS processing/)

- Johan

On Fri, Jul 22, 2016 at 2:09 AM Scott Palmer  wrote:

>
> > On Jul 21, 2016, at 6:18 PM, Richard Bair 
> wrote:
> >
> > Hi Steve,
> >
> > It could be a benchmark problem, although I wouldn’t be surprised at all
> if the benchmark was exercising the platform in some way that was CPU
> limited. Assuming it is CPU limited (and not going multi-core), I think the
> problem really comes down to what Markus said:
> >
> >> The limiting factor is the single-thread architecture of rather all
> parts of JavaFX. The only real difference you see between machines is not
> correlating with neither number of CPU cores nor GPU cores, but only with
> CPU frequency, roughly spoken. Short term fixes will only provide little
> improvement, by optimizing the critical execution path (i. e. produce hot
> spot histogram using a profiler), for example improvement clipping,
> caching, etc. Huge performance optimizations need an architectural change
> within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to
> use parallel execution in lots of places. Typical design patterns would be
> parallel iterations, work-stealing executors, fibers (a.k.a cooperative
> multi-threading, a.k.a CompletableFuture), and last but not least
> partitioned rendering (a.k.a tiled rendering).
> >>
> >> I am pretty sure you can add a lot more ideas to the list and produce
> great performance, scaling linearly with number of CPU cores / GPU cores,
> but this somes at a cost: Risk to introduce hard to track bugs, and needed
> manpower.
> >>
> >> If somebody has at least a lot of free spare time, I am pretty sure
> Kevin could easily provide a huge set of work items in this area. :-)
> >
> >
> > JavaFX was setup to be multi-threaded — in fact there are always at
> least 2 threads — the application / scene graph thread and the render
> thread. Going way, way back the goal was for multi-core
> computation/rasterizing on the NG side (Prism), but it didn’t get done for
> a variety of reasons. I couldn’t even say what kind of performance win/loss
> it would bring. I’m sure for some workloads it would be way better,but for
> many others it probably wouldn’t make any difference. A lot of other more
> pressing features had to be implemented first which would allow people to
> build apps at all on top of FX (like controls and effects and animations
> 

Re: Scene graph performance

[Felix Bembrick]

Sorry, take 2.

Thanks - that's very helpful.

I have been concentrating on profiling the Java aspects of FXMark so this gives 
me more things to try.

I will report back with my findings.

Blessings,

Felix

> On 22 Jul 2016, at 19:02, Vadim Pakhnushev  
> wrote:
> 
>> On 22.07.2016 11:15, Felix Bembrick wrote:
>> Hi Vadim,
>> 
>> I am very open-minded about this. Anything is possible (including, as I 
>> mentioned, that I wrote FXMark very poorly).
>> 
>> Can you help by detailing what tools you use to track CPU/GPU usage?
> 
> I personally use Process Hacker (I'm on Windows) and it's sitting in my tray 
> all the time so I can see exactly what's happening.
> Process Explorer is another very popular task manager replacement with 
> similar features.
> It can show you overall system load as well as individual process's 
> performance graphs including GPU load.
> 
> Vadim

Re: Scene graph performance

[Felix Bembrick]

> On 22 Jul 2016, at 19:02, Vadim Pakhnushev  
> wrote:
> 
>> On 22.07.2016 11:15, Felix Bembrick wrote:
>> Hi Vadim,
>> 
>> I am very open-minded about this. Anything is possible (including, as I 
>> mentioned, that I wrote FXMark very poorly).
>> 
>> Can you help by detailing what tools you use to track CPU/GPU usage?
> 
> I personally use Process Hacker (I'm on Windows) and it's sitting in my tray 
> all the time so I can see exactly what's happening.
> Process Explorer is another very popular task manager replacement with 
> similar features.
> It can show you overall system load as well as individual process's 
> performance graphs including GPU load.
> 
> Vadim

Re: Scene graph performance

[Vadim Pakhnushev]

On 22.07.2016 11:15, Felix Bembrick wrote:

Hi Vadim,

I am very open-minded about this. Anything is possible (including, as I 
mentioned, that I wrote FXMark very poorly).

Can you help by detailing what tools you use to track CPU/GPU usage?


I personally use Process Hacker (I'm on Windows) and it's sitting in my 
tray all the time so I can see exactly what's happening.
Process Explorer is another very popular task manager replacement with 
similar features.
It can show you overall system load as well as individual process's 
performance graphs including GPU load.


Vadim

Re: Scene graph performance

[Felix Bembrick]

Hi Vadim,

I am very open-minded about this. Anything is possible (including, as I 
mentioned, that I wrote FXMark very poorly).

Can you help by detailing what tools you use to track CPU/GPU usage?

I am sure finding out the exact nature of what is happening and what is causing 
it will help everyone.

And, quite frankly, I actually hope that my coding *is* the problem and not 
JavaFX.

Why? 

Because I can fix my coding.

Blessings,

Felix

> On 22 Jul 2016, at 17:56, Vadim Pakhnushev  
> wrote:
> 
> Felix,
> 
> For me it's very useful to track CPU/GPU usage while running a benchmark.
> Could it be that your very fast machine is limited by some synchronization 
> issues and CPU/GPU is essentially idle while slower machine is running 100% 
> CPU?
> 
> Vadim
> 
>> On 22.07.2016 3:35, Felix Bembrick wrote:
>> 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.
>> 
>> 
> 

Re: Scene graph performance

[Vadim Pakhnushev]

Felix,

For me it's very useful to track CPU/GPU usage while running a benchmark.
Could it be that your very fast machine is limited by some 
synchronization issues and CPU/GPU is essentially idle while slower 
machine is running 100% CPU?


Vadim

On 22.07.2016 3:35, Felix Bembrick wrote:

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.

Re: Scene graph performance

[Felix Bembrick]

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  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 
> wrote:
> >
> > Are you using nodes, 

Re: Scene graph performance

[Scott Palmer]

> On Jul 21, 2016, at 6:18 PM, Richard Bair  wrote:
> 
> Hi Steve,
> 
> It could be a benchmark problem, although I wouldn’t be surprised at all if 
> the benchmark was exercising the platform in some way that was CPU limited. 
> Assuming it is CPU limited (and not going multi-core), I think the problem 
> really comes down to what Markus said:
> 
>> The limiting factor is the single-thread architecture of rather all parts of 
>> JavaFX. The only real difference you see between machines is not correlating 
>> with neither number of CPU cores nor GPU cores, but only with CPU frequency, 
>> roughly spoken. Short term fixes will only provide little improvement, by 
>> optimizing the critical execution path (i. e. produce hot spot histogram 
>> using a profiler), for example improvement clipping, caching, etc. Huge 
>> performance optimizations need an architectural change within JavaFX's 
>> "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel 
>> execution in lots of places. Typical design patterns would be parallel 
>> iterations, work-stealing executors, fibers (a.k.a cooperative 
>> multi-threading, a.k.a CompletableFuture), and last but not least 
>> partitioned rendering (a.k.a tiled rendering).
>> 
>> I am pretty sure you can add a lot more ideas to the list and produce great 
>> performance, scaling linearly with number of CPU cores / GPU cores, but this 
>> somes at a cost: Risk to introduce hard to track bugs, and needed manpower.
>> 
>> If somebody has at least a lot of free spare time, I am pretty sure Kevin 
>> could easily provide a huge set of work items in this area. :-)
> 
> 
> JavaFX was setup to be multi-threaded — in fact there are always at least 2 
> threads — the application / scene graph thread and the render thread. Going 
> way, way back the goal was for multi-core computation/rasterizing on the NG 
> side (Prism), but it didn’t get done for a variety of reasons. I couldn’t 
> even say what kind of performance win/loss it would bring. I’m sure for some 
> workloads it would be way better,but for many others it probably wouldn’t 
> make any difference. A lot of other more pressing features had to be 
> implemented first which would allow people to build apps at all on top of FX 
> (like controls and effects and animations and so forth), and Prism has served 
> us really well.
> 
> There are a few places we could play with fork/join to see if we can get 
> performance boosts, all of which would be tricky and have to be done very 
> carefully because they are part of highly tuned code paths:
> Computing and applying CSS styles
> Computing bounds
> Computing layout


^ That.  Computing layout and CSS is the most time consuming aspect of my 
application.
I get pauses of more than a second or two in some cases for only a few thousand 
nodes.

Recently JDK-8153329 was fixed which helped a little (e.g. 3-4 seconds to add a 
panel full of controls to my UI down to 2-3 seconds)… but it lead me to believe 
that these highly tuned code paths could use more tuning.

Adding or remove nodes can be very expensive.  I suspect changes in bounds can 
be very expensive.  And it seems that Path drawing is expensive.

That’s what would help my application the most.

Cheers,

Scott

Re: Scene graph performance

[Hervé Girod]

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  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  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  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  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  
>> 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 listcompared 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  
 wrote:
 
 Yep.

Re: Scene graph performance

[Richard Bair]

Hi Steve,

It could be a benchmark problem, although I wouldn’t be surprised at all if the 
benchmark was exercising the platform in some way that was CPU limited. 
Assuming it is CPU limited (and not going multi-core), I think the problem 
really comes down to what Markus said:

> The limiting factor is the single-thread architecture of rather all parts of 
> JavaFX. The only real difference you see between machines is not correlating 
> with neither number of CPU cores nor GPU cores, but only with CPU frequency, 
> roughly spoken. Short term fixes will only provide little improvement, by 
> optimizing the critical execution path (i. e. produce hot spot histogram 
> using a profiler), for example improvement clipping, caching, etc. Huge 
> performance optimizations need an architectural change within JavaFX's 
> "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel 
> execution in lots of places. Typical design patterns would be parallel 
> iterations, work-stealing executors, fibers (a.k.a cooperative 
> multi-threading, a.k.a CompletableFuture), and last but not least partitioned 
> rendering (a.k.a tiled rendering).
> 
> I am pretty sure you can add a lot more ideas to the list and produce great 
> performance, scaling linearly with number of CPU cores / GPU cores, but this 
> somes at a cost: Risk to introduce hard to track bugs, and needed manpower.
> 
> If somebody has at least a lot of free spare time, I am pretty sure Kevin 
> could easily provide a huge set of work items in this area. :-)


JavaFX was setup to be multi-threaded — in fact there are always at least 2 
threads — the application / scene graph thread and the render thread. Going 
way, way back the goal was for multi-core computation/rasterizing on the NG 
side (Prism), but it didn’t get done for a variety of reasons. I couldn’t even 
say what kind of performance win/loss it would bring. I’m sure for some 
workloads it would be way better,but for many others it probably wouldn’t make 
any difference. A lot of other more pressing features had to be implemented 
first which would allow people to build apps at all on top of FX (like controls 
and effects and animations and so forth), and Prism has served us really well.

There are a few places we could play with fork/join to see if we can get 
performance boosts, all of which would be tricky and have to be done very 
carefully because they are part of highly tuned code paths:
Computing and applying CSS styles
Computing bounds
Computing layout
Syncing state between scene graph and the render graph
Updating state on the render graph (not sure much time is spent here…)
Rasterizing (fonts, anti-aliased glyphs, etc)

Some of these might be easier to try out than others. For example, using 
multiple threads at sync time should be safe, but probably won’t see much of 
any gain (as it takes a couple MS maximum to do this sync anyway). The more 
difficult one is probably making the rasterizing steps multi-threaded, but that 
would probably bring the biggest win. Computing bounds and layout and CSS in 
parallel would be very tricky, but if it could be done, would likely result in 
a nice speed boost for very large scenes (it would have no impact on rendering 
performance).

Cheers!
Richard

Re: Scene graph performance

[Richard Bair]

Hi Herve,

Thanks for chiming in. I agree.  From my own experience and benchmarking with 
other app-dev GUI toolkits, JavaFX performs very well for a very wide range of 
use cases. That being said, performance was always a passion of mine and I know 
there is more to be had. I like Kevin’s idea of updating to newer graphics 
pipelines too. Our first goal was to get broad coverage, so OpenGL ES 2 and DX 
9 were the hot ticket. But getting onto the newer pipelines opens up a lot of 
additional possibilities.

Richard

> On Jul 21, 2016, at 2:33 PM, Hervé Girod  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  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  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  
> 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 
> listcompared 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  
>>> wrote:
>>> 
>>> Yep.

Re: Scene graph performance

[Felix Bembrick]

I agree that the original question has led to a discussion of a somewhat 
different nature and I accept that the benchmark itself may be problematic.

But others have reported similar observation using different benchmarks.

> On 22 Jul 2016, at 07:42, Steve Hannah  wrote:
> 
> I've just been a fly on the wall for this thread, but ... I think this
> thread has gone off track a bit.  Felix's original observation was that he
> got the same benchmark results from two machines that should produce
> different results because one is more powerful than the other in both CPU
> and GPU).  The talk of things that could be done to improve JavaFX
> performance don't seem relevant to this.  The real question is, why is a
> slow computer performing as well as a fast computer?
> 
> The answer is likely far simpler than the explanations proposed here.
> Either there is a problem with the benchmark methodology, there is an
> environment difference that isn't being accounted for (which is also a
> methodology problem), or there is some mechanism that is throttling
> performance.
> 
> My hunch is that there is a problem with the benchmark.
> 
> Steve
> 
>> On Thu, Jul 21, 2016 at 2:33 PM, Hervé Girod  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 
>>> 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 
>> 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 
>> 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
>> listcompared 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.
> 
> 
> 
> -- 
> Steve Hannah
> Web Lite Solutions Corp.

Re: Scene graph performance

[Felix Bembrick]

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  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  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  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  
> 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 
> listcompared 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  
>>> wrote:
>>> 
>>> Yep.

Re: Scene graph performance

[Felix Bembrick]

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.
> 
> -- Kevin
> 
> 
> Richard Bair wrote:
>> I think you just nailed it on the head Markus :-).
>> 
>>  
>>> On Jul 21, 2016, at 10:56 AM, Markus KARG <mar...@headcrashing.eu> wrote:
>>> 
>>> The limiting factor is the single-thread architecture of rather all parts 
>>> of JavaFX. The only real difference you see between machines is not 
>>> correlating with neither number of CPU cores nor GPU cores, but only with 
>>> CPU frequency, roughly spoken. Short term fixes will only provide little 
>>> improvement, by optimizing the critical execution path (i. e. produce hot 
>>> spot histogram using a profiler), for example improvement clipping, 
>>> caching, etc. Huge performance optimizations need an architectural change 
>>> within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to 
>>> use parallel execution in lots of places. Typical design patterns would be 
>>> parallel iterations, work-stealing executors, fibers (a.k.a cooperative 
>>> multi-threading, a.k.a CompletableFuture), and last but not least 
>>> partitioned rendering (a.k.a tiled rendering).
>>> 
>>> I am pretty sure you can add a lot more ideas to the list and produce great 
>>> performance, scaling linearly with number of CPU cores / GPU cores, but 
>>> this somes at a cost: Risk to introduce hard to track bugs, and needed 
>>> manpower.
>>> 
>>> If somebody has at least a lot of free spare time, I am pretty sure Kevin 
>>> could easily provide a huge set of work items in this area. :-)
>>> 
>>> -Markus
>>> 
>>> -Original Message-
>>> From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf 
>>> Of Dr. Michael Paus
>>> Sent: Donnerstag, 21. Juli 2016 12:07
>>> To: openjfx-dev@openjdk.java.net
>>> Subject: Re: Scene graph performance
>>> 
>>> Hi Felix,
>>> I have written various tests like the ones you use in FXMark and I have 
>>> obtained similar results. I have even tried to substitute 2D shapes by 
>>> using 3D MeshViews in the hope that this would give better performance but 
>>> the results were not that good. Of course all this depends on the specific 
>>> test case but in general I see that a JavaFX application which makes heavy 
>>> use of graphics animations is completely CPU-bounded.
>>> The maximum performance is reached when one CPU/Core is at 100%.
>>> The performance of your graphics hardware seems to be almost irrelevant.
>>> I could for example run four instances of the same test with almost the 
>>> same performance at the same time. In this case all 4 cores of my machine 
>>> were at 100%. This proves that the graphics hardware is not the limiting 
>>> factor. My machine is a MacBook Pro with Retina graphics and a dedicated 
>>> NVidia graphics card which is already a couple of years old and certainly 
>>> not playing in the same league as your high-power card.
>>> I myself have not yet found a way to really speed up the graphics 
>>> performance and I am a little bit frustrated because of that. But it is not 
>>> only the general graphic performance which is a problem. There are also a 
>>> lot of other pitfalls into which you can stumble and which can bring your 
>>> animations to a halt or even crash your system. Zooming for example is one 
>>> of these issues.
>>> 
>>> I would like to have some exchange on these issues and how to best address 
>>> them but my impression so far is that there are only very view people 
>>> interested in that. (I hope someone can prove me wrong on this :-)
>>> 
>>> Michael
>>> 
>>>> Am 20.07.16 um 04:14 schrieb Felix Bembrick:
>>>>
>>>> Having written and tested FXMark on various platforms and devices, one 
>>>> thing has really struck me as quite "odd".
>>>> 
>>>> I started work on FXMark as a kind of side project a while ago and, at the 
>>>> time, my machine was powerful but not "super powerful".
>>>> 
>>>> So when I purchased a new machine with just about the highest specs 
>>>> available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X 
>>>> 

RE: Scene graph performance

[Markus KARG]

The limiting factor is the single-thread architecture of rather all parts of 
JavaFX. The only real difference you see between machines is not correlating 
with neither number of CPU cores nor GPU cores, but only with CPU frequency, 
roughly spoken. Short term fixes will only provide little improvement, by 
optimizing the critical execution path (i. e. produce hot spot histogram using 
a profiler), for example improvement clipping, caching, etc. Huge performance 
optimizations need an architectural change within JavaFX's 
"scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel 
execution in lots of places. Typical design patterns would be parallel 
iterations, work-stealing executors, fibers (a.k.a cooperative multi-threading, 
a.k.a CompletableFuture), and last but not least partitioned rendering (a.k.a 
tiled rendering).

I am pretty sure you can add a lot more ideas to the list and produce great 
performance, scaling linearly with number of CPU cores / GPU cores, but this 
somes at a cost: Risk to introduce hard to track bugs, and needed manpower.

If somebody has at least a lot of free spare time, I am pretty sure Kevin could 
easily provide a huge set of work items in this area. :-)

-Markus

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of 
Dr. Michael Paus
Sent: Donnerstag, 21. Juli 2016 12:07
To: openjfx-dev@openjdk.java.net
Subject: Re: Scene graph performance

Hi Felix,
I have written various tests like the ones you use in FXMark and I have 
obtained similar results. I have even tried to substitute 2D shapes by using 3D 
MeshViews in the hope that this would give better performance but the results 
were not that good. Of course all this depends on the specific test case but in 
general I see that a JavaFX application which makes heavy use of graphics 
animations is completely CPU-bounded.
The maximum performance is reached when one CPU/Core is at 100%.
The performance of your graphics hardware seems to be almost irrelevant.
I could for example run four instances of the same test with almost the same 
performance at the same time. In this case all 4 cores of my machine were at 
100%. This proves that the graphics hardware is not the limiting factor. My 
machine is a MacBook Pro with Retina graphics and a dedicated NVidia graphics 
card which is already a couple of years old and certainly not playing in the 
same league as your high-power card.
I myself have not yet found a way to really speed up the graphics performance 
and I am a little bit frustrated because of that. But it is not only the 
general graphic performance which is a problem. There are also a lot of other 
pitfalls into which you can stumble and which can bring your animations to a 
halt or even crash your system. Zooming for example is one of these issues.

I would like to have some exchange on these issues and how to best address them 
but my impression so far is that there are only very view people interested in 
that. (I hope someone can prove me wrong on this :-)

Michael

Am 20.07.16 um 04:14 schrieb Felix Bembrick:
> Having written and tested FXMark on various platforms and devices, one 
> thing has really struck me as quite "odd".
>
> I started work on FXMark as a kind of side project a while ago and, at 
> the time, my machine was powerful but not "super powerful".
>
> So when I purchased a new machine with just about the highest specs 
> available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX 
> Titan X GPUs in SLI mode, I was naturally expecting to see significant 
> performance improvements when I ran FXMark on this machine.
>
> But to my surprise, and disappointment, the scene graph animations ran 
> almost NO faster whatsoever!
>
> So then I decided to try FXMark on my wife's entry-level Dell i5 PC 
> with a rudimentary (single) GPU and, guess what - almost the same 
> level of performance (i.e. FPS and smoothness etc.) was achieved on 
> this considerably less powerful machine (in terms of both CPU and GPU).
>
> So, it seems there is some kind of "performance wall" that limits the 
> rendering speed of the scene graph (and this is with full speed 
> animations enabled).
>
> What is the nature of this "wall"? Is it simply that the rendering 
> pipeline is not making efficient use of the GPU? Is too much being done on 
> the CPU?
>
> Whatever the cause, I really think it needs to be addressed.
>
> If I can't get better performance out of a machine that scores in the 
> top 0.01% of all machine in the world in the 3DMark Index than an 
> entry level PC, isn't this a MAJOR issue for JavaFX?
>
> Blessings,
>
> Felix

Re: Scene graph performance

[Richard Bair]

Have you guys profiled the application to see where the CPU time is spent? How 
many nodes in the app?

In the past the majority of CPU time has been spent in one or more of the 
following (not sure if it still applies):
  - Computing changed bounds (a lot of work was done to speed this up, but I 
think it was always a single thread doing the work)
  - Synchronizing state to the render graph (a lot of work was done here too, 
so I wouldn’t expect this to be the problem area)
  - Walking the render graph to render shapes
  - Rasterization (A lot of optimization went here too, but it is still 
essentially a CPU bound operation)
  - Reading results back from the card (this is sometimes the culprit when it 
is slow on old hardware and fast on new hardware)

These are all CPU bound tasks.

I think that there are two angles to look at. First, we always wanted to break 
down the render stage into some parallel pipeline. Adobe Flex was good at this, 
where they’d saturate every CPU you had during the CPU intensive rasterization 
phase and scene graph computation phase. Depending on your particular test, 
this might actually be the bottleneck. So the idea here is to optimize the CPU 
tasks, which will (hopefully) remove CPU from the bottleneck and allow the GPU 
to take on more of the burden. You should also do some research or experiments 
with regards to battery life to make sure using more cores doesn’t make things 
worse (and if it does, to then have a flag to indicate the amount of 
parallelism). You also have to be careful because IIRC (and I may not!) if a 
lot of CPU activity happens on some laptops they’ll kick into a “high 
performance” mode, which is sometimes what you want, and sometimes not. Games 
are happy to kick you into that mode (and drain your battery faster as a 
result) whereas business apps rarely want to do that.

Another angle to look at is more of a research direction in the graphics 
rendering. We spent quite a lot of time looking into ways to go “shader all the 
way” and avoid having to use a software rasterizer at all. The state of the art 
as likely advanced from the last time I looked at it, but at the time there 
really wasn’t anything that we could find that was really ready for production 
in terms of producing 2D screens using 3D that really gave you the polish of 
2D. Also, the scene graph semantics are fundamentally painter’s algorithm, 
since this is what everybody is used to when coming from a 2D background. But 
that’s not the way it works in 3D. In 3D you feed a bunch of meshes to the 
video card and it determines which pixels to render and which are occluded and 
don’t need to be rendered. But when you have multiple geometries at the same 
z-depth, then the card can have “z-fighting” where it renders the pixels from 
some items below you and some above. There are techniques to try to overcome 
this, but at least the last time we looked at it (according to my increasingly 
dimming memory!) there wasn’t a really brilliant solution to the problem. 
Anti-aliasing and transparency were big problems too.

 DETOUR

Normal things that you would have in 2D like shadows, text, even rounded 
rectangles have historically been produced using various 2D algorithms and 
blend modes and so forth. Most people don’t even realize the degree to which 
their view of what a real 2D screen looks like has been tainted by the 
techniques that were available for producing those screens. Many (most? all? at 
least it was at the time) game developers recognized this and used 2D toolkits 
with CPU rasterization to produce their 2D screens and then overlaid this on 3D 
content. The normal way to do this is to render the 2D images in photoshop or 
something and then slice it up and load the pngs into the graphics card on app 
startup and then scale those to produce the images. This is fine, but in a 
general purpose toolkit like FX you can’t just do that, because we allow 
programmatic access to the scene graph and people can modify the “images” in 
real time. So we draw them and cache them and reuse the cached images whenever 
possible etc. A lot was done in order to try to optimize this part of the 
problem.

When I was benchmarking this stuff, we blew away pretty much everybody who was 
in the 2D+3D general purpose graphics toolkit world. We never tried to compete 
with the game vendors (like Unity). We weren’t trying to be a pure 3D scene 
graph. There was a huge discussion about this early on in FX, as to how to 
marry the 2D and 3D worlds. Developers in these different lands come at the 
problem differently, in terms of how they understand their world (y-up or 
y-down? 0,0 in the middle? Every scene scaled? Or 0,0 in top left and pixel 
scaled by default? Anti-aliasing?). We decided it was for 2D developers who 
wanted advanced graphics and animations, and a better toolkit for building apps 
(not games). We figured that for people who wanted to program games, we were 
never going to be really 

Re: Scene graph performance

[Felix Bembrick]

I would add that neither JOGL nor LWJGL have these issues.

Yes, I know they are somewhat different "animals", but the point is, clearly 
*Java* is NOT the cause.

> On 21 Jul 2016, at 20:07, Dr. Michael Paus  wrote:
> 
> Hi Felix,
> I have written various tests like the ones you use in FXMark and I have
> obtained similar results. I have even tried to substitute 2D shapes by
> using 3D MeshViews in the hope that this would give better performance
> but the results were not that good. Of course all this depends on the
> specific test case but in general I see that a JavaFX application which
> makes heavy use of graphics animations is completely CPU-bounded.
> The maximum performance is reached when one CPU/Core is at 100%.
> The performance of your graphics hardware seems to be almost irrelevant.
> I could for example run four instances of the same test with almost the
> same performance at the same time. In this case all 4 cores of my machine
> were at 100%. This proves that the graphics hardware is not the limiting
> factor. My machine is a MacBook Pro with Retina graphics and a dedicated
> NVidia graphics card which is already a couple of years old and certainly
> not playing in the same league as your high-power card.
> I myself have not yet found a way to really speed up the graphics performance
> and I am a little bit frustrated because of that. But it is not only the 
> general
> graphic performance which is a problem. There are also a lot of other pitfalls
> into which you can stumble and which can bring your animations to a halt
> or even crash your system. Zooming for example is one of these issues.
> 
> I would like to have some exchange on these issues and how to best address
> them but my impression so far is that there are only very view people 
> interested
> in that. (I hope someone can prove me wrong on this :-)
> 
> Michael
> 
>> Am 20.07.16 um 04:14 schrieb Felix Bembrick:
>> Having written and tested FXMark on various platforms and devices, one
>> thing has really struck me as quite "odd".
>> 
>> I started work on FXMark as a kind of side project a while ago and, at the
>> time, my machine was powerful but not "super powerful".
>> 
>> So when I purchased a new machine with just about the highest specs
>> available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X
>> GPUs in SLI mode, I was naturally expecting to see significant performance
>> improvements when I ran FXMark on this machine.
>> 
>> But to my surprise, and disappointment, the scene graph animations ran
>> almost NO faster whatsoever!
>> 
>> So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a
>> rudimentary (single) GPU and, guess what - almost the same level of
>> performance (i.e. FPS and smoothness etc.) was achieved on this
>> considerably less powerful machine (in terms of both CPU and GPU).
>> 
>> So, it seems there is some kind of "performance wall" that limits the
>> rendering speed of the scene graph (and this is with full speed animations
>> enabled).
>> 
>> What is the nature of this "wall"? Is it simply that the rendering pipeline
>> is not making efficient use of the GPU? Is too much being done on the CPU?
>> 
>> Whatever the cause, I really think it needs to be addressed.
>> 
>> If I can't get better performance out of a machine that scores in the top
>> 0.01% of all machine in the world in the 3DMark Index than an entry level
>> PC, isn't this a MAJOR issue for JavaFX?
>> 
>> Blessings,
>> 
>> Felix
> 
> 

Re: Scene graph performance

[Felix Bembrick]

Hi Michael,

Thanks for your response.

This is what I suspected: what is ostensibly a hardware accelerated toolkit 
seems to barely utilise the GPU for scene graph animations.

But, even with that, my machine has dual high performance 16-core Xeons while 
my wife's machine has a single 2-core i5 and STILL the performance is barely 
indistinguishable!

I would love to discuss this with you off-list as I see this as the biggest 
impediment to expanding the use cases for JavaFX.

The Canvas node seems to perform quite well but, other than that, we basically 
have a toolkit suitable for forms with the occasional transition thrown in.

I think I can fix these issues and I will continue to further investigate the 
cause.

It's somewhat ridiculous that on my same machine I can write pure OpenGL code 
(not Direct3D) and animate 5000 Quake 3D characters and achieve at least 1000 
FPS.

I don't think we can blame Java the language as Java is not running on the GPU. 

It appears though that not much else is either!

(It seems the Quantum Renderer thread is working really, really hard. The GPU 
should be doing most of the heavy lifting).

Felix

> On 21 Jul 2016, at 20:07, Dr. Michael Paus  wrote:
> 
> Hi Felix,
> I have written various tests like the ones you use in FXMark and I have
> obtained similar results. I have even tried to substitute 2D shapes by
> using 3D MeshViews in the hope that this would give better performance
> but the results were not that good. Of course all this depends on the
> specific test case but in general I see that a JavaFX application which
> makes heavy use of graphics animations is completely CPU-bounded.
> The maximum performance is reached when one CPU/Core is at 100%.
> The performance of your graphics hardware seems to be almost irrelevant.
> I could for example run four instances of the same test with almost the
> same performance at the same time. In this case all 4 cores of my machine
> were at 100%. This proves that the graphics hardware is not the limiting
> factor. My machine is a MacBook Pro with Retina graphics and a dedicated
> NVidia graphics card which is already a couple of years old and certainly
> not playing in the same league as your high-power card.
> I myself have not yet found a way to really speed up the graphics performance
> and I am a little bit frustrated because of that. But it is not only the 
> general
> graphic performance which is a problem. There are also a lot of other pitfalls
> into which you can stumble and which can bring your animations to a halt
> or even crash your system. Zooming for example is one of these issues.
> 
> I would like to have some exchange on these issues and how to best address
> them but my impression so far is that there are only very view people 
> interested
> in that. (I hope someone can prove me wrong on this :-)
> 
> Michael
> 
>> Am 20.07.16 um 04:14 schrieb Felix Bembrick:
>> Having written and tested FXMark on various platforms and devices, one
>> thing has really struck me as quite "odd".
>> 
>> I started work on FXMark as a kind of side project a while ago and, at the
>> time, my machine was powerful but not "super powerful".
>> 
>> So when I purchased a new machine with just about the highest specs
>> available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X
>> GPUs in SLI mode, I was naturally expecting to see significant performance
>> improvements when I ran FXMark on this machine.
>> 
>> But to my surprise, and disappointment, the scene graph animations ran
>> almost NO faster whatsoever!
>> 
>> So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a
>> rudimentary (single) GPU and, guess what - almost the same level of
>> performance (i.e. FPS and smoothness etc.) was achieved on this
>> considerably less powerful machine (in terms of both CPU and GPU).
>> 
>> So, it seems there is some kind of "performance wall" that limits the
>> rendering speed of the scene graph (and this is with full speed animations
>> enabled).
>> 
>> What is the nature of this "wall"? Is it simply that the rendering pipeline
>> is not making efficient use of the GPU? Is too much being done on the CPU?
>> 
>> Whatever the cause, I really think it needs to be addressed.
>> 
>> If I can't get better performance out of a machine that scores in the top
>> 0.01% of all machine in the world in the 3DMark Index than an entry level
>> PC, isn't this a MAJOR issue for JavaFX?
>> 
>> Blessings,
>> 
>> Felix
> 
> 

Re: Scene graph performance

[Dr. Michael Paus]

Hi Felix,
I have written various tests like the ones you use in FXMark and I have
obtained similar results. I have even tried to substitute 2D shapes by
using 3D MeshViews in the hope that this would give better performance
but the results were not that good. Of course all this depends on the
specific test case but in general I see that a JavaFX application which
makes heavy use of graphics animations is completely CPU-bounded.
The maximum performance is reached when one CPU/Core is at 100%.
The performance of your graphics hardware seems to be almost irrelevant.
I could for example run four instances of the same test with almost the
same performance at the same time. In this case all 4 cores of my machine
were at 100%. This proves that the graphics hardware is not the limiting
factor. My machine is a MacBook Pro with Retina graphics and a dedicated
NVidia graphics card which is already a couple of years old and certainly
not playing in the same league as your high-power card.
I myself have not yet found a way to really speed up the graphics 
performance
and I am a little bit frustrated because of that. But it is not only the 
general
graphic performance which is a problem. There are also a lot of other 
pitfalls

into which you can stumble and which can bring your animations to a halt
or even crash your system. Zooming for example is one of these issues.

I would like to have some exchange on these issues and how to best address
them but my impression so far is that there are only very view people 
interested

in that. (I hope someone can prove me wrong on this :-)

Michael

Am 20.07.16 um 04:14 schrieb Felix Bembrick:

Having written and tested FXMark on various platforms and devices, one
thing has really struck me as quite "odd".

I started work on FXMark as a kind of side project a while ago and, at the
time, my machine was powerful but not "super powerful".

So when I purchased a new machine with just about the highest specs
available including 2 x Xeon CPUs and (especially) 4 x NVIDIA GTX Titan X
GPUs in SLI mode, I was naturally expecting to see significant performance
improvements when I ran FXMark on this machine.

But to my surprise, and disappointment, the scene graph animations ran
almost NO faster whatsoever!

So then I decided to try FXMark on my wife's entry-level Dell i5 PC with a
rudimentary (single) GPU and, guess what - almost the same level of
performance (i.e. FPS and smoothness etc.) was achieved on this
considerably less powerful machine (in terms of both CPU and GPU).

So, it seems there is some kind of "performance wall" that limits the
rendering speed of the scene graph (and this is with full speed animations
enabled).

What is the nature of this "wall"? Is it simply that the rendering pipeline
is not making efficient use of the GPU? Is too much being done on the CPU?

Whatever the cause, I really think it needs to be addressed.

If I can't get better performance out of a machine that scores in the top
0.01% of all machine in the world in the 3DMark Index than an entry level
PC, isn't this a MAJOR issue for JavaFX?

Blessings,

Felix