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,
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
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
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
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
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:
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
I did not look at the presentation, but perhaps the Raspberry Pi itself is one
if the key reasons for these performance problems. It is a great but limited
device. I'm not taking at face value the claim that the Pi beats last year
generation smartphones architecture.
And I'm not sure that
But the impact on performance that arises simply by increasing the number of
nodes is not limited to low powered devices like the Pi. I am interested to
know what the cause of that effect is.
On 30 Dec 2013, at 11:03, Hervé Girod herve.gi...@gmail.com wrote:
I did not look at the
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.
10 matches
Mail list logo
