yep that's exactly what I figured out too...Pi needs some special treatment and optimized for Pi doesn't mean optimized for embedded in general cause Beagleboard really showed different behavior.
Cheers, Gerrit > Am 30.12.2013 um 19:48 schrieb Jasper Potts <jasper.po...@oracle.com>: > > Removing/Adding nodes has a high cost. So doing that in a animation or any > performance important area is not a good idea. I have gone to lengths to hide > the node creation with apps I have built. > > Using small number of nodes with most drawing done with css can be good > practice. But CSS can be expensive so if it changes often then might be > better using code and Region API. > > Path performance is bad on Pi for two reasons. 1) CPU is week so takes a > while to compute mask pixels 2) the bus is slow between GPU and CPU. So > changing paths is bad but drawing a static path many times should be fine. > > The Pi has special performance characteristics that are unique because of > very slow CPU and data bus but really fast GPU. By the numbers it's GPU is as > fast as Intel HD found in most corporate laptops. But the CPU is slower than > a Pentium II. > > That means performance tuning for Pi may not give same results on other > devices. For example Beagle Board is quite different as CPU is almost 2x Pi > but GPU power is more in live with CPU and much slower than Pi. > > Jasper > > > >> On Dec 30, 2013, at 3:39 AM, Tom Eugelink <t...@tbee.org> wrote: >> >> >> "removing and re-adding nodes to the scenegraph", yeah, sounds like a good >> suspect. >> >> I just got offered a commercial JavaFX project (which I ended up not doing >> because of all my other work) where the client said that they tried doing it >> themselves, but had all kinds of architectural issues they needed me to >> solve. Personally I experienced something similar Gerrit explains here when >> trying to write my Agenda control, it appears the first time you do JavaFX >> you'll be doing it wrong. Even though the learning curve is much less than >> Swing's, there still is one. It may be a good idea to get some "best >> practices" going. >> >> Tom >> >> >>> On 2013-12-30 12:09, Gerrit Grunwald wrote: >>> I'm pretty sure that one performance drawback in these gauges is related to >>> constantly removing and re-adding nodes to the scenegraph in the >>> layoutChildren method. This might be the reason why even static drawing >>> code will be handled even if it was not necessary. One reason why in the >>> Enzo controls I add nodes only once to the scenegraph and from that point >>> on only modify the nodes. >>> On the Pi I think one reason for performance problems might be (not sure) >>> that paths are rastered by the cpu and because I use a lot of paths and the >>> cpu is not that powerful it leads to performance decrease when using lots >>> of nodes containing paths but that's more a guess... >>> >>> Cheers, >>> >>> Gerrit >>> >>> mail han.s...@muenster.de >>> web harmonic-code.org >>> twitter hansolo_ >>> >>>> Am 30.12.2013 um 11:01 schrieb Felix Bembrick <felix.bembr...@gmail.com>: >>>> >>>> Yes Tom, I also came to the conclusion that most of the nodes in those >>>> (awesome) gauges are largely static and would rarely, if ever, become >>>> "dirty" so the inference that it's excessive work on the scenegraph would >>>> seem unlikely as the cause of the performance degradation. >>>> >>>> It does look to me that there is some inherent impact on performance >>>> associated simply with having more nodes. I hope Richard or someone with >>>> intimate knowledge of the innards of JavaFX rendering could chime in >>>> here... >>>> >>>> >>>>> On 30 December 2013 20:50, Tom Eugelink <t...@tbee.org> wrote: >>>>> >>>>> >>>>> I also watched Gerrits presentation, and he put a lot of emphasis on the >>>>> difference between drawing using nodes and drawing using CSS. One of the >>>>> examples was one of his famous gauges, where he used a number of gradients >>>>> to draw the background. His initial approach was one-node-per-gradient, so >>>>> a node for the background, one for the upper shadow, one for the lower, >>>>> etc. This resulted in a lot of nodes and he says the Pi has a maximum of >>>>> about 120 nodes. Now, these background nodes (and all others that make up >>>>> the dial) are static nodes, they do not easily go dirty. So I'm not sure >>>>> that that is the problem Gerrit experienced. >>>>> >>>>> That said, the other approach where he tries to do as much in one node as >>>>> possible, using CSS, insets and multiple backgrounds/fills seems like a >>>>> much clear implementation. So there are other advantages as well. But >>>>> never >>>>> the less it would be interesting to see what the performance issue really >>>>> is, given your statement. >>>>> >>>>> Tom >>>>> >>>>> >>>>> >>>>> >>>>>> On 2013-12-30 1:50, Jasper Potts wrote: >>>>>> >>>>>> My experience was it is not the number of Nodes. It's the number of Nodes >>>>>> that are changed/dirty in a single frame. So having a scene with 500 >>>>>> nodes >>>>>> may take a couple of seconds to render first time but then you can >>>>>> animate >>>>>> a couple of those nodes at 60fps if you done make too big a area dirty. >>>>>> >>>>>> Performance issues are one of two things too much SceneGraph work or too >>>>>> much Graphics card work. You can use pulse logger to determine which >>>>>> issue >>>>>> you are having. >>>>>> >>>>>> Jasper >>>>>> >>>>>> On Dec 29, 2013, at 3:15 PM, Felix Bembrick <felix.bembr...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> I just watched the excellent presentation by Gerrit Grunwald "Use the >>>>>>> force >>>>>>> Luke" on Parleys and in it he mentions that one of the key ways to >>>>>>> improve >>>>>>> performance is to limit the number of nodes in the scenegraph. He also >>>>>>> mentions that on such devices as the Raspberry Pi the maximum number of >>>>>>> nodes viable before performance degrades significantly is very, very >>>>>>> limited. Further, he then goes on to demonstrate that the equivalent >>>>>>> visual appearance can be achieved by other means such as CSS, Canvas >>>>>>> etc. >>>>>>> where the number of nodes is much less. >>>>>>> >>>>>>> The implication here is that there is a performance-limiting effect of >>>>>>> Nodes. If the device's GPU is capable of rendering certain graphics >>>>>>> primitives, effects, transitions etc. and JavaFX is capable of "making >>>>>>> them >>>>>>> happen" by one way or another, I am curious as to why the simple >>>>>>> presence >>>>>>> of Nodes limits performance so significantly. >>>>>>> >>>>>>> The obvious conclusion is that Nodes use memory and perhaps the >>>>>>> associated >>>>>>> overhead is the cause but given that we are largely talking about GPU >>>>>>> based >>>>>>> processing I find it hard to believe that it's as simple as this. >>>>>>> >>>>>>> So what is it about the nature of Nodes that causes them to have such a >>>>>>> limiting effect on performance? >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Felix >> >>
