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.



> Am 30.12.2013 um 19:48 schrieb Jasper Potts <>:
> 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 <> 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
>>> web
>>> twitter hansolo_
>>>> Am 30.12.2013 um 11:01 schrieb Felix Bembrick <>:
>>>> 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 <> 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 <>
>>>>>>> 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

Reply via email to