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

https://javafx-jira.kenai.com/issues/?filter=12938&jql=project%20%3D%20RT%20AND%20resolution%20%3D%20Unresolved%20AND%20labels%20%3D%20performance%20ORDER%20BY%20key%20ASC%2C%20priority%20DESC

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

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

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

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

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

Benchmarks:
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 
(https://wiki.openjdk.java.net/display/OpenJFX/Performance+Ideas)  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).

Cheers
Richard

Reply via email to