Scene graph performance

[Scott Palmer]

> On Jul 21, 2016, at 6:18 PM, Richard Bair <richard.bair at oracle.com> wrote:
> 
> Hi Steve,
> 
> It could be a benchmark problem, although I wouldn’t be surprised at all if the benchmark was exercising the platform in some way that was CPU limited. Assuming it is CPU limited (and not going multi-core), I think the problem really comes down to what Markus said:
> 
>> The limiting factor is the single-thread architecture of rather all parts of JavaFX. The only real difference you see between machines is not correlating with neither number of CPU cores nor GPU cores, but only with CPU frequency, roughly spoken. Short term fixes will only provide little improvement, by optimizing the critical execution path (i. e. produce hot spot histogram using a profiler), for example improvement clipping, caching, etc. Huge performance optimizations need an architectural change within JavaFX's "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel execution in lots of places. Typical design patterns would be parallel iterations, work-stealing executors, fibers (a.k.a cooperative multi-threading, a.k.a CompletableFuture), and last but not least partitioned rendering (a.k.a tiled rendering).
>> 
>> I am pretty sure you can add a lot more ideas to the list and produce great performance, scaling linearly with number of CPU cores / GPU cores, but this somes at a cost: Risk to introduce hard to track bugs, and needed manpower.
>> 
>> If somebody has at least a lot of free spare time, I am pretty sure Kevin could easily provide a huge set of work items in this area. :-)
> 
> 
> JavaFX was setup to be multi-threaded — in fact there are always at least 2 threads — the application / scene graph thread and the render thread. Going way, way back the goal was for multi-core computation/rasterizing on the NG side (Prism), but it didn’t get done for a variety of reasons. I couldn’t even say what kind of performance win/loss it would bring. I’m sure for some workloads it would be way better,but for many others it probably wouldn’t make any difference. A lot of other more pressing features had to be implemented first which would allow people to build apps at all on top of FX (like controls and effects and animations and so forth), and Prism has served us really well.
> 
> There are a few places we could play with fork/join to see if we can get performance boosts, all of which would be tricky and have to be done very carefully because they are part of highly tuned code paths:
> Computing and applying CSS styles
> Computing bounds
> Computing layout


^ That.  Computing layout and CSS is the most time consuming aspect of my application.
I get pauses of more than a second or two in some cases for only a few thousand nodes.

Recently JDK-8153329 was fixed which helped a little (e.g. 3-4 seconds to add a panel full of controls to my UI down to 2-3 seconds)… but it lead me to believe that these highly tuned code paths could use more tuning.

Adding or remove nodes can be very expensive.  I suspect changes in bounds can be very expensive.  And it seems that Path drawing is expensive.

That’s what would help my application the most.

Cheers,

Scott