Anybody interested in jitter ought to look at https://javafx-jira.kenai.com/browse/RT-26702
Richard On May 29, 2013, at 5:18 PM, Richard Bair <[email protected]> wrote: > >> 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
