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.

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

Reply via email to