JavaFX performance for complex visualisations

[Dr. Michael Paus]

Hi Richard,

first of all thank you for the feedback on my post. I've put some more 
comment inline.

Am 04.12.2012 21:41, schrieb Richard Bair:
> 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!)
This is of course true but tell me how far do you really get if you only 
have these elements available?
You cannot even draw a simple filled triangle without creating a path 
and thus slowing down your application.
A graphically intensive business application without paths seems to be a 
very specific corner case to me but
maybe it is just me who feels so. What I have in mind when I talk about 
such applications are large diagrams,
floor plans, vector maps with a lot of symbols on them and so on.
>> 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).
Have you seen this?
https://developer.nvidia.com/nv-path-rendering
Ok, this is NVIDIA specific but maybe worth considering for a platform 
specific optimization.
>   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.
It is interesting that you mention Android and iOS here so often :-) 
although that does not help us so much on the desktop.
>
> 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.
I am waiting for that.
>
>> 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.
It is true, that I did not reanalyze this particular case with the 
latest builds but if you say that the FX rasterizer is now on par with 
the old Java2D
rasterizer then this is really good news. It is a pitty that I do not 
have the old test anymore and cannot easily reanalyze this.
>
>> 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?
I thought it might be possible to define a 3D mesh where all 
z-coordinates are zero and use that for more complicated shapes in order 
to avoid the paths.
Ideally the API would even provide 2D specific variants of these 3D meshes.

Michael

-- 
--------------------------------------------------------------------------------------
Dr. Michael Paus, Chairman of the Java User Group Stuttgart e.V. (JUGS).
For more information visit www.jugs.de.