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 :
>
> Removing/Adding nodes has a hi
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 ex
"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 the
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 contr
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 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, s
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.
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 wrote:
>
> I did not look at the presentation, but perhaps the
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 canva
