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
> 
> 

Reply via email to