JavaFX graphics performance and suitability for advanced animations

Wed May 29 11:11:50 PDT 2013

Ok, thanks.

As we have a lot of dynamic elements in our map overlay, I will post about performance (compared to our swing based implementation, which is currently rather good for us), as soon as we have finished our implementation.

Herve

Sent from my iPhone

On 29 mai 2013, at 19:59, Richard Bair <richard.bair at oracle.com> wrote:

> I would start with scene graph nodes and see how it goes. The Canvas should be thought of as a nice utility for drawing images, rather than a hook into the low-level drawing machinery.
> 
> Richard
> 
> 
> On May 29, 2013, at 10:23 AM, Hervé Girod <herve.girod at gmail.com> wrote:
> 
>> Hello,
>> 
>> Concerning my previous question, is it planned to provide some kind of "shape " drawing for JavaFX 8 in the graphic context, or is it safer to assume that the scene graph will be the preferred way to handle this (apart from the svgpath drawing of course)?
>> 
>> I have the same kind of question about attributed strings which are handled using the TextFlow node in JavaFX 8, but for which there is no direct way to handle them in the canvas graphic context.
>> 
>> We are currently trying to draw complex and animated map overlays in JavaFX.
>> 
>> We did that drawing directly in the graphic context in swing, and we assumed that it was safe to use the JavaFX canvas graphic context to do the same thing, but are now not so sure that its the right way to handle it. I'm not talking about the current JavaFX 2.2 API, but rather what you are planning for Java FX 8.
>> 
>> Herve
>> 
>> Sent from my iPhone
>> 
>> On 29 mai 2013, at 02:40, Herve Girod <herve.girod at gmail.com> wrote:
>> 
>>> Thanks for your answer!
>>> 
>>> As for our experience, we are currently migrating a big UI application (Java ARINC 661 Server: http://sourceforge.net/projects/j661/)  from being Swing-based to JavaFX based. We still keep the Swing compatibility, but we found that using the JavaFX scene graph makes things MUCH more simple for us. And in our very preliminary tests it does seem that our performance is good (the application is almost completely ported and working, but several of our custom widgets implementations still have to be implemented in JavaFX, so we don't have direct comparisons yet).
>>> 
>>> However, as you talk about the scene graph / the canvas API, I have a question. We are mostly rendering controls and Shapes (exactly what JavaFX scene graph is about), but we also have to render Map overlays (with waypoints, flight plans, etc...). We used to do it by overriding the paintComponent method of a custom Component in our Swing implementation, dealing directly with the Graphics2D Layer. The "natural" path for us with JavaFX would be to use the Canvas widget, and GraphicContext, but reading your answer, I begin to suspect that we could maybe achieve a better performance with a simpler architecture by using directly the scenegraph for that too. What do you think?
>>> 
>>> Herve
>>> 
>>> 
>>> 2013/5/29 Richard Bair <richard.bair at oracle.com>
>>>> Hi John,
>>>> 
>>>> > 1.       Can someone from Oracle please outline the full range of
>>>> > applications for which JavaFX is or will be suitable for?
>>>> 
>>>> That's a pretty broad question. Lots of stuff? At a minimum everything Swing and SWT were used for, as well as mobile and embedded UIs, rich media, graphics, etc. I don't expect somebody to write Halo 5 with it.
>>>> 
>>>> > 2.       Is there something inherent in the JavaFX architecture (such as
>>>> > CPU/GPU interaction, the performance of the JVM or the Java language itself)
>>>> > that limits its suitability and thus effectiveness in advanced
>>>> > animations/visualisations?
>>>> 
>>>> Absolutely not, in fact, quite the opposite. The basic architecture (threading model, GPU usage model, etc) is designed for high concurrency and throughput. Some of the features in Controls though (like CSS lookup, color derivation, etc) put a tax on performance. When it wasn't exposed in the API, every design decision is made with performance as a for most thought. When it comes to API usability is considered primarily but performance is also always considered (along with security). And for every feature that adds weight, there is a way to avoid it when absolutely necessary.
>>>> 
>>>> > 3.       Is this choppiness and lack of smoothness I have experienced
>>>> > typical of JavaFX performance or is it some issue with my
>>>> > environment/drivers etc.?
>>>> 
>>>> Hard to say. I saw a couple weeks ago a machine where scrolling the table view was 14fps whereas it was 320fps for me. The difference was the other system was falling back to the software pipeline. To determine what you're seeing, we need to know whether what you're running is producing consistently slow results or erratic results. Also, we need to know whether you are render bound or compute bound. What's taking so long to complete?
>>>> 
>>>> We have seen situations where we are preparing a frame but never rendering it, which might also be contributing to the choppiness.
>>>> 
>>>> > 4.       Is JavaFX more targeted at form-based UIs rather than high
>>>> > performance graphics?
>>>> 
>>>> No.
>>>> 
>>>> > 5.       Do you have any other comments on JavaFX and its suitability for
>>>> > advanced animations and visualizations?
>>>> 
>>>> The biggest issue at present architecturally is that we don't expose any way for you to *really* draw without the scene graph. The Canvas gets you partway there, but ultimately that guy is still just buffering up drawing commands and issuing them later against a texture, rather than allowing you to go directly down to OpenGL. So that's a feature that is missing that is going to impact some people.
>>>> 
>>>> Instead, you have to do everything with the scene graph which in more advanced scenarios means a huge scene graph and tons of memory.
>>>> 
>>>> We're still making a lot of progress on the raw performance side. We had an embedded hack-fest a couple weeks ago in which performance on desktop went from 320-800+fps on table view scrolling, which in large measure came down to reducing the number of state switches on the graphics card (and the resulting decrease in the number of OpenGL calls).
>>>> 
>>>> However choppiness is often the culprit in perceived performance rather than actual fps.
>>>> 
>>>> One thing you can try is to run your application with -Djavafx.pulseLogger=true and analyze the output. This records the amount of time spent in various phases of the pulse, the number of dirty nodes processed per frame, etc. One thing I saw a couple weeks back, for instance, was that if more than 15 nodes are dirty (or is it 12?) then we punt on determining the dirty region and accumulate the entire parent. This is a heuristic used to trade off figuring out how big the dirty area is against just drawing it -- sometimes it is cheaper to do the former, sometimes the latter.
>>>> 
>>>> Also each individual dirty region probably comes with some overhead in terms of setup for each render pass (each unique dirty area ends up getting its own render pass), and this fixed cost has not been analyzed and perhaps needs to be factored in to our determination of the number of dirty regions we support, or the heuristic in any case.
>>>> 
>>>> Are your slow examples reproducible? If so we need the test case. Is there an issue filed? We can't fix things we can't reproduce. We spend a *considerable* amount of time and energy on performance and for the things we're measuring we're doing well. As the saying goes "what's measured, improves". After the switch to gradle and the new project layout, one thing I'm going to look at is using JMH[2] in OpenJFX so we can write micro benchmarks and have them easy for everybody to run and contribute to. Our current set of micro benchmarks are based on the predecessor of JMH which was the JRockit benchmark suite and was proprietary (hence we cannot just open source our existing benchmarks without doing some rewrite).
>>>> 
>>>> [1] Attributed to Peter Drucker http://blog.johnrchildress.com/2012/06/05/key-business-metrics-and-milestones/
>>>> [2] http://hg.openjdk.java.net/code-tools/jmh/file/tip/jmh-samples/src/main/java/org/openjdk/jmh/samples/
> 