JavaFX performance for complex visualisations

[John Smith]

> In fact, we found that on embedded the GPU was the major bottleneck and we needed to move more stuff onto the CPU.

Seeing as a lot of the rendering work is done on the CPU and not the GPU, is it (or can it) be optimized to make use of multi-core CPUs, or must the rendering be single threaded?

Michael asked me this question in a forum thread and I didn't have any answer for it.

-----Original Message-----
From: openjfx-dev-bounces at openjdk.java.net [mailto:openjfx-dev-bounces at openjdk.java.net] On Behalf Of Richard Bair
Sent: Tuesday, December 04, 2012 12:41 PM
To: Dr. Michael Paus
Cc: openjfx-dev at openjdk.java.net
Subject: Re: JavaFX performance for complex visualisations

Hi Michael,

The thrust of your argument here I think is sound -- that lines are a lot faster than paths, and that the 3D Mesh should be quite a bit faster. There are just a couple minor things I wanted to clarify.

> According to my experience JavaFX is currently not able to handle 
> graphically intensive applications.

Depends on what you are doing that is "graphically intense" -- if it is a lot of paths (thousands) then yes, this is slow. If it is a lot of images and lines and effects and such, then actually you can do a heck of a lot with FX (which is graphically intense!)

> One reason for this is that all drawing of path based primitives is 
> done in software and not in hardware.

There are a couple reasons for this which are sound. First, general path drawing in shaders is not entirely possible. There are algorithms or proofs of concept that do a pretty good job of it in most cases but not in the general case (at least, we haven't seen it). Second, on mobile / embedded you would die if you depended on the GPU to do these things (the CPU is way, WAY more powerful than the GPU). In fact, we found that on embedded the GPU was the major bottleneck and we needed to move more stuff onto the CPU. Incidentally, Android does the same thing (for the same reason).

Another thing is that we limit ourselves to certain shader levels that are available on OpenGL ES 2 for the sake of embedded. With higher shader level support, we could do more.

There is also a quality / speed tradeoff involved here. The way we do our antialiasing produces very high quality output, but requires that we upload a mask. On iOS, the highest MSAA level you can support is 4. Our Antialiasing is several orders of magnitude better in terms of the final results.

Fundamentally, 2D applications are very different from 3D. GPU's (even mobile GPU's) are fantastic at 3D because that's what they're designed for. We're doing the state of the art when it comes to representing 2D on 3D hardware. The problem is that in some cases, you would like to dial down the performance and have more of a 3D like experience in your application, and in those cases, today, there isn't anything available. Of course we aim to fix this with our 3D support that we're adding.

> But a polygon is a path and thus is rendered in software and this 
> software renderer is in many cases even 2-3 times slower than the one 
> used in AWT.

Just out of curiosity, when is the last time you measured this? By our own benchmarks FX is faster than Ductus (Java2D) now. We did a bunch of performance work in the rasterizer a few months ago. I wonder if your test is available and works on the dev builds of 8 such that this could be reanalyzed? I'm keen to make sure we are faster.

> I hope this will change with the upcoming 3D support where we will 
> also get more hardware accelerated drawing primitives which will hopefully also be usable in 2D.

When you say "also usable in 2D", what do you mean? For example, we can have a node that contains all the 3D mesh stuff, and "flatten" it for inclusion in the 2D scene. Is that what you mean?

Richard