JavaFX graphics performance and suitability for advanced animations

Richard Bair richard.bair at
Wed May 29 17:18:19 PDT 2013

> As ever, just a suggestion. I'll leave it at that so we can get back to the real issues. 

So, back to the real issues :-). Here is a good JIRA query:

I see 228 issues (you might see fewer if they are marked internal, but I can't imagine many if any should be internal). I am (painfully) going through each one and categorizing them, such as:

G Salami
B Targeted Win
R Major Win

B RT-2892: Improve performance of Gaussian-based effects
B RT-2908: Use scaled kernel to improve DropShadow performance for node scale factors < 1
B RT-5347: Prism: finish drop/inner shadow optimizations
B RT-5420: DropShadow effects significantly affect performance
B RT-6935: ColorAdjust effect consumes a lot of memory which could lead to OOM exception
B RT-8890: Merge and some Blend effects should optimize rendering to destination

B RT-5069: Text node computes complete text layout, even if clipped to a much smaller size

Scene Graph:
G RT-5525: Group will get bounds change notification when child's bounds change, even if change in child didn't alter bounds of Group

G RT-5835: Fix for RT-5788 disabled an optimization for anti-aliased rectangles
B RT-6968: Prism should support 2-byte gray-alpha .png format
B RT-8722: Strokes and fills of Paths slower than flash

R RT-2893: Enable multi-threaded processing of software-based effects when >= 2 cores available

G RT-7644: Math.floor and Math.ceil take up a lot of cpu time

The colors probably won't come through, so I marked them as "G" to mean "Green", "B" for Blue, "R" for Red. Anyway, I am breaking down the issues first by area (Threading, Scene Graph, etc) and then by type. "Salami" is "death by a thousand cuts" -- something that you fix because you should, but you aren't going to see anything from it unless it is getting executed a BAZILLION times. "Targeted Win" means that if you were to write a micro benchmark that just exercised this one code path and did it heavily (like having 18,000 rectangles with drop shadows or whatever), then fixing this issue would result in a significant improvement in that benchmark. "Major Win" is something that would pretty much across the board have a major positive impact on performance.

So I've only gone through 15 or so issues (closed a couple of them) of the 220+, so I've got a long way to go. Once I've categorized these, I'll add the different issues to the wiki (  and link to the most prominent JIRA issues. I'm not going to keep the wiki up to date as new issues are filed as that would be a constant effort -- the wiki will have a link to a JIRA query that will do that. But what I can do is update all the JIRA issues so that they are tagged with "salami", "targeted_win", "major_win" or whatever (maybe a better naming system is needed but whatever I'll make something up). Then there will be a dashboard with the different issues broken out. The Wiki is mostly to have a place where we can add verbiage around the different performance ideas, why they matter, and what the idea is for improving them, etc.

The next step is to have somebody prototype writing some FX micro benchmarks using JMH. We're going to create a project inside rt to house these benchmarks when they're written. There are multiple ways contributions can happen here. You can write a micro benchmark that we can include in the project so everybody can run it. This will give us the ability to measure something, and "that which is measured improves". Another way to contribute is to take some issue and chase it down to completion, with a patch and everything. Another way is to take micro benchmarks provided by somebody else and run them on your configuration and report back results.

If any of the issues in that query are particularly interesting to you, then let us know you're looking at it and dive in! Start a new thread for the particular issue (or better discuss it in the JIRA itself).


More information about the openjfx-dev mailing list