P3
Testing the Effects framework (specifically BoxBlur) with the same code atached in RT-5024, I got the following performance (CPU usage data is global for that quad-core CPU so 25% is the maximum):
1 Ball: 665fps (from 995fps without effect)
16 Balls: 116fps (from 665fps)
32 Balls: 60fps (from 665fps)
128 Balls: 17fps / 15% CPU (from 400fps / 22% CPU: 23X less frames)
512 Balls: ~2,2fps / 25% CPU (from 82fps / 23% CPU: 37X less frames)
The base 1 Balls score is meaningless because on that test the animation is capped by the animation engine's pulse (forced to 1KHz); even 10 Balls score the same 995fps in my system. Also, the scores for 16 and 32 Balls are identical; both tests have minimal CPU usage, so once again the FPS rate should be limited by timing artifacts. Because of this, I can't compute with any significant precision how much slower the effect makes these tests. I did that calculation only for 128 and 512 Balls, where the score is limited by CPU.
I was expecting a sensible cost in performance, but not in the 20X-40X range. Memory allocation is not the answer: for the 1 Balls test, -verbosegc reveals only ~25% more GC logs with the effect enabled. Looking at CPU usage in the same test, it's <1% in the standard run (Windows's Task Manager shows a stable "00"), but it jumps to ~8% (32% of a single core). In the 128 Balls test, normalizing CPU usage to the score, the test with effects uses 0,88% CPU/frame, without effects it's 0,055% CPU/frame; so the effects increase CPU usage 16X. In the 512 Balls test, the same calculation results in a 40X disadvantage. Very similar scores in a laptop with a T7250 CPU and a much lower-end NVidia GeForce 8400M.
Notice that the base animation (without effects) is really trivial, it just moves a small ImageView around the screen, in fact all the CPU usage that the normal test shows (sans effects) is due to scene graph overheads (dirty rects or something else). These overheads were huge in 1.0/1.1, but largely fixed in Marina's redesigned scene graph. This makes the coparision with/without Effects somewhat unfair, because I'm comparing to a baseline app that does almost no work. OTOH, JavaFX Effects are implemented on top of shaders (when available - like in my test systems) and, AFAIK, the amount and complexity of shading work necessary for my benchmark, even with a high number of Balls, should also be in the "almost no work" category, as that work can be completely offloaded to a GPU that is capable of much more than this. So I suppose that there is some big inneficiency in the architecture, perhaps less than ideal integration to the JFX/J2D rendering pipeline.
This performance is certainly not a problem for RIA apps, even with some animation centered in user interactions, e.g. dragging a component that has a drop shadow, sending an icon to the trashbin with a motion blur, glowing a menu or button, etc. I can live with 60-120fps performance in a forms-based GUI with a few dozen components. ;-) But the overhead of effects is probably prohibitive for advanced uses, in sophisticated animations that need a hundred of nodes or more (action games, simulation, etc.).
1 Ball: 665fps (from 995fps without effect)
16 Balls: 116fps (from 665fps)
32 Balls: 60fps (from 665fps)
128 Balls: 17fps / 15% CPU (from 400fps / 22% CPU: 23X less frames)
512 Balls: ~2,2fps / 25% CPU (from 82fps / 23% CPU: 37X less frames)
The base 1 Balls score is meaningless because on that test the animation is capped by the animation engine's pulse (forced to 1KHz); even 10 Balls score the same 995fps in my system. Also, the scores for 16 and 32 Balls are identical; both tests have minimal CPU usage, so once again the FPS rate should be limited by timing artifacts. Because of this, I can't compute with any significant precision how much slower the effect makes these tests. I did that calculation only for 128 and 512 Balls, where the score is limited by CPU.
I was expecting a sensible cost in performance, but not in the 20X-40X range. Memory allocation is not the answer: for the 1 Balls test, -verbosegc reveals only ~25% more GC logs with the effect enabled. Looking at CPU usage in the same test, it's <1% in the standard run (Windows's Task Manager shows a stable "00"), but it jumps to ~8% (32% of a single core). In the 128 Balls test, normalizing CPU usage to the score, the test with effects uses 0,88% CPU/frame, without effects it's 0,055% CPU/frame; so the effects increase CPU usage 16X. In the 512 Balls test, the same calculation results in a 40X disadvantage. Very similar scores in a laptop with a T7250 CPU and a much lower-end NVidia GeForce 8400M.
Notice that the base animation (without effects) is really trivial, it just moves a small ImageView around the screen, in fact all the CPU usage that the normal test shows (sans effects) is due to scene graph overheads (dirty rects or something else). These overheads were huge in 1.0/1.1, but largely fixed in Marina's redesigned scene graph. This makes the coparision with/without Effects somewhat unfair, because I'm comparing to a baseline app that does almost no work. OTOH, JavaFX Effects are implemented on top of shaders (when available - like in my test systems) and, AFAIK, the amount and complexity of shading work necessary for my benchmark, even with a high number of Balls, should also be in the "almost no work" category, as that work can be completely offloaded to a GPU that is capable of much more than this. So I suppose that there is some big inneficiency in the architecture, perhaps less than ideal integration to the JFX/J2D rendering pipeline.
This performance is certainly not a problem for RIA apps, even with some animation centered in user interactions, e.g. dragging a component that has a drop shadow, sending an icon to the trashbin with a motion blur, glowing a menu or button, etc. I can live with 60-120fps performance in a forms-based GUI with a few dozen components. ;-) But the overhead of effects is probably prohibitive for advanced uses, in sophisticated animations that need a hundred of nodes or more (action games, simulation, etc.).