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